Plugin crashes on Release mode, works fine in Debug

Hello!
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;
---
    WaveCalculatorController::~WaveCalculatorController()
{
    // 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");
    }
    clearSingletonInstance();
}
}
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.”

Rail

2 Likes

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!!!

2 Likes

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