triggerDuplicateParamIDCheck causing a leak on plugin scan

General JUCE discussion
1

Hey guys,

It seems triggerDuplicateParamIDCheck is causing a leak when Reaper does a plugin scan. I commented it out from AudioProcessor::addParameter and the leak went away. I’m guessing a copy was made and wasn’t cleaned up before the plugin exited since we are just doing a scan and not staying up for very long.

Figuring it out was tough because I couldn’t use CRTDBG_MAP_ALLOC since there’s a conflict with juce. Using the pragma trick recommended in this thread Conflict with _CRTDBG_MAP_ALLOC (Visual Studio) didn’t help it because the leak was in juce itself. It was also maddening figuring out the leak only happened on scan! One repro, then it’s gone until the next change lol.

I realize this leak has zero direct user impact since the code is debug only and furthermore is a one time leak on scan. For development though it’s quite alarming when Reaper detects a change and scans with every plugin change, causing the leak to repro and spew a lot of noisy warnings in the VS debugger.

For now I think I’ll just disable the check.

Thanks!
-Scott

2

Although unlikely, it is possible for a host to just free memory without calling the appropriate destructors. I learned it the hard way with Apple’s FxPlug plugins, it could happen in other hosts as well, since after scan, they don’t care if the plugin is in a workable state or not:

[…] That said, what you are seeing is normal. During shutdown, the apps do not free every piece of memory that they allocated. Since the operating system will free all memory used by the app’s process, the apps just quit and let the OS reclaim the memory rather than manually going through every object and deallocating them. This significantly speeds up shutdown times for users.

Just a thought, that would explain, why it only happens during scan…

3

I should have mentioned the leak is new with juce 5, maybe new with 5.4.4 actually since the unique_ptr stuff was added.

The destructor is being called like it always has been.

It’s definitely caused by something in triggerDuplicateParamIDCheck since the leak goes away if I remove the call (commented out) below:

void AudioProcessor::addParameter (AudioProcessorParameter* param)
{
    jassert (param != nullptr);
    parameterTree.addChild (std::unique_ptr<AudioProcessorParameter> (param));

    param->processor = this;
    param->parameterIndex = flatParameterList.size();
    flatParameterList.add (param);

    // This causes a leak on plugin scan.  https://forum.juce.com/t/triggerduplicateparamidcheck-causing-a-leak-on-plugin-scan/35280

    //triggerDuplicateParamIDCheck();
}

There’s a block of 32 bytes leaked for every parameter added to the plugin:

{805868} normal block at 0x0000000017833400, 16 bytes long.
 Data: < N              > B0 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113738} normal block at 0x00000000201F6130, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113717} normal block at 0x00000000201F6550, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113696} normal block at 0x00000000201F6970, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113675} normal block at 0x00000000201F6910, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113654} normal block at 0x00000000201F68B0, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113633} normal block at 0x00000000201F6A90, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113612} normal block at 0x00000000201F6010, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD 
{113591} normal block at 0x00000000201F5B90, 32 bytes long.
 Data: <XN              > 58 4E 06 F6 FF 7F 00 00 01 00 00 00 CD CD CD CD

Etc.

Didn’t happen with juce 4.3.1

(Sorry I’m new to posting code here…not sure how the tags work(Edit: Thanks richie!) )

4

just surround anything you want preformatted with three back ticks ( ` )

Or select the text and click : image

:slight_smile:

1 Like
5

I see, so it’s leaks detected by VS, not the Juce leak detector…

There are a few references about these leaks on the forum, they seem to be messages from the message queue, that haven’t been delivered.
The conclusion on other threads about that was, it would be an overhead to govern for these to be destroyed correctly, and they are only happening when finishing the process, so they were left there, and best be ignored.