Plugin crashes on Release mode, works fine in Debug

I’m creating an audioPlugin with JUCE and something weird happens when I close it.
If Visual Studio’s compiler is set on Debug mode everything works fine, if it’s set on release the plugin crashes when I shut it down (click the close button on the interface). I’ve also tried to compile and use it with ableton but then it crashes when I delete it from the track.

The crash says:

  • Exception thrown at 0x00007FFEE9F53416 (ntdll.dll) in Claudea.exe: 0xC0000005: Access violation writing location 0x0000000000000024.
  • The call stack:
    → ntdll.dll!RtlpWaitOnCriticalSection()
    → ntdll.dll!RtlpEnterCriticalSectionContended()
    → ntdll.dll!RtlEnterCriticalSection()
    …Program adresses
    → kernel32.dll!BaseThreadInitThunk()
    → ntdll.dll!RtlUserThreadStart()

I’m using a map of ints and objects that inherit from a highResolutionTimer from a singleton with deleteOnShutdown. These are some pieces of code that might be usefull

class WaveCalculatorController: juce::DeletedAtShutdown
    std::map<int, std::shared_ptr<WaveCalculator>> waveCalculators;
    // this ensures that no dangling pointers are left when the
    // singleton is deleted.
    for (auto& x : waveCalculators)
        if (x.second.unique())juce::Logger::writeToLog("Unique");
        else juce::Logger::writeToLog("Not Unique");
class WaveCalculator: public juce::HighResolutionTimer, public SampleCalculator


The logger on the function above is not logging anything…(it should log not unique)
I hope I have included all the info needed and that some of you guys can help me :slight_smile: since english is not my first language and I don’t know even how to start debugging… thanks in advance!

Hi there, I don’t think we can tell what you’ve done wrong.
But, I suspect it’s the optimisation that’s causing the problem so why not debug it optimised?
This will help:
“disable selected optimizations for each source code file until you locate the file and the optimization that is causing the problem.”



I’ve tried to disable the optimizations and it didn’t work.
I’ve also seen that the problem is when DeletedOnShoutdown ends up calling the destructor of a listener. It locks the listener and then it crashes there.

Hi, I meant enable optimisation in debug, so that it still crashes but you’ll have some chance of finding its location. That link describes the way to debug release builds. The /RTC option mentioned looks useful too, although I haven’t tried it myself.

Sometimes I resort to commenting out sections of code or function calls just to narrow it down, or printing things to the console to find out how far it gets in a function.

At least you know the rough area it’s crashing in now, it seems. Although, if you have a memory stomper, it may be something else trampling over memory - from any thread.

Yes, if I comment out the lock just before the AudioProcessorParameter tries to delete it, it works. Now I can’t figure out what might be making the waitOnCriticalSection() crash

void AudioProcessorParameter::removeListener (AudioProcessorParameter::Listener* listenerToRemove)
    const ScopedLock sl (listenerLock); //Comment
    listeners.removeFirstMatchingValue (listenerToRemove);

Does it crash or wait for ever?

It throws Access violation writing location exception

Guys if finally solved it!!
Turns out I wasn’t deleting my sub-components on the PluginEditor destructor but on a jucesingleton inheriting deleteAtShutdown. I now make sure that all the subcomponents are destroyed in the plugin editor destructor and the problem it’s been solved. Thank you all for helping!!!


Why not use unique_ptr’s or component member variables? They’ll get deleted for you…
I haven’t used ‘new’ or ‘delete’ for several years now. :grinning:

1 Like