AsyncUpdaterMessage leak issue!

General JUCE discussion
1

Hi,

After having searched for a long long time on a memory leak in my application, I have found (thanks to Memory Validator) the two objects which created this leak.
In its opinion, it was two AsyncUpdaterMessage that were not released from somewhere… So, I put the JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR macro in AsyncUpdaterMessage class. And that gives me the following magic message :
*** Leaked objects detected: 2 instance(s) of class AsyncUpdaterMessage

So… First of all : why don’t put this macro in this class ?
Secondly, if I have a memory leak at this level, from where and why does it happen ?

I explain my environment of test :

  • I have a VST plugin host application, compiled using JUCE static library
  • I launch an instance from my own VST plugin, compiled using JUCE amalgamated header
  • I ask for displaying its UI
  • I close the main plugin host application

This is done to test application under stress, like closing application without having closed plugins’ UI.
I have search everywhere and my functions for closing plugins’ UI are well called, and plugins exist normally.

I paste the call stack of those two objects :

AsyncUpdaterMessage : 36 : bytes at 0x0030f638 : [c:\sdks\juce\src\events\juce_asyncupdater.cpp Line 59]
  Allocation location
  ThreadID: 00004352 (Juce Message Thread) Timestamp: 8/31 20:02:04 726ms (Lifetime:00:00:16:333ms) Request ID: 00017614
   0x54235c5e signal_debug.dll juce::AsyncUpdater::AsyncUpdater : [c:\sdks\juce\src\events\juce_asyncupdater.cpp Line 59]
   0x54451515 signal_debug.dll juce::MouseInputSourceInternal::MouseInputSourceInternal : [c:\sdks\juce\src\gui\components\mouse\juce_mouseinputsource.cpp Line 48]
   0x54451423 signal_debug.dll juce::MouseInputSource::MouseInputSource : [c:\sdks\juce\src\gui\components\mouse\juce_mouseinputsource.cpp Line 506]
   0x5455285c signal_debug.dll juce::Desktop::createMouseInputSources : [c:\sdks\juce\src\native\windows\juce_win32_windowing.cpp Line 2785]
   0x5439cfde signal_debug.dll juce::Desktop::Desktop : [c:\sdks\juce\src\gui\components\juce_desktop.cpp Line 44]
   0x5439d4ff signal_debug.dll juce::Desktop::getInstance : [c:\sdks\juce\src\gui\components\juce_desktop.cpp Line 63]
   0x54427b9e signal_debug.dll juce::LookAndFeel::getDefaultLookAndFeel : [c:\sdks\juce\src\gui\components\lookandfeel\juce_lookandfeel.cpp Line 355]
   0x54395f59 signal_debug.dll juce::Component::getLookAndFeel : [c:\sdks\juce\src\gui\components\juce_component.cpp Line 1999]
   0x543bacbd signal_debug.dll juce::ComboBox::lookAndFeelChanged : [c:\sdks\juce\src\gui\components\controls\juce_combobox.cpp Line 420]
   0x543b8192 signal_debug.dll juce::ComboBox::ComboBox : [c:\sdks\juce\src\gui\components\controls\juce_combobox.cpp Line 62]
   0x5457da35 signal_debug.dll lacoustics::plugin::signal::gui::Editor::Editor : [c:\users\nicolas\documents\projects\plugins\signal\sources\lacoustics\plugin\signal\gui\editor.cpp Line 15]
 AsyncUpdaterMessage : 36 : bytes at 0x0030f598 : [c:\sdks\juce\src\events\juce_asyncupdater.cpp Line 59]
  Allocation location
  ThreadID: 00004352 (Juce Message Thread) Timestamp: 8/31 20:02:04 726ms (Lifetime:00:00:16:333ms) Request ID: 00017610
   0x54235c5e signal_debug.dll juce::AsyncUpdater::AsyncUpdater : [c:\sdks\juce\src\events\juce_asyncupdater.cpp Line 59]
   0x5439ceb6 signal_debug.dll juce::Desktop::Desktop : [c:\sdks\juce\src\gui\components\juce_desktop.cpp Line 43]
   0x5439d4ff signal_debug.dll juce::Desktop::getInstance : [c:\sdks\juce\src\gui\components\juce_desktop.cpp Line 63]
   0x54427b9e signal_debug.dll juce::LookAndFeel::getDefaultLookAndFeel : [c:\sdks\juce\src\gui\components\lookandfeel\juce_lookandfeel.cpp Line 355]
   0x54395f59 signal_debug.dll juce::Component::getLookAndFeel : [c:\sdks\juce\src\gui\components\juce_component.cpp Line 1999]
   0x543bacbd signal_debug.dll juce::ComboBox::lookAndFeelChanged : [c:\sdks\juce\src\gui\components\controls\juce_combobox.cpp Line 420]
   0x543b8192 signal_debug.dll juce::ComboBox::ComboBox : [c:\sdks\juce\src\gui\components\controls\juce_combobox.cpp Line 62]
   0x5457da35 signal_debug.dll lacoustics::plugin::signal::gui::Editor::Editor : [c:\users\nicolas\documents\projects\plugins\signal\sources\lacoustics\plugin\signal\gui\editor.cpp Line 15]
   0x5457f05f signal_debug.dll lacoustics::plugin::signal::Signal::createEditor : [c:\users\nicolas\documents\projects\plugins\signal\sources\lacoustics\plugin\signal\signal.cpp Line 118]
   0x542269b0 signal_debug.dll juce::AudioProcessor::createEditorIfNeeded : [c:\sdks\juce\src\audio\processors\juce_audioprocessor.cpp Line 228]
   0x540ac2a0 signal_debug.dll JuceVSTWrapper::createEditorComp : [c:\sdks\juce\src\audio\plugin_client\vst\juce_vst_wrapper.cpp Line 1034]
2

http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=7427

3

Ok… So I have seen this thread…
Is that the same problem ?
If it is so, it could be a greater problem that I thought…
Deliver applications with memory leaks is FAR AWAY from my point of view of being a conscientious developer…
Is there any way to deal about those leaks ?

P.S. : burnt… Indeed, it seems to be the same problem… damn !

4

Sometimes you have to lose a battle to win the war.

5

Very well put.

Please don’t talk about this like it’s some kind of sloppy mistake. Obviously I hate leaky code, but in this case the only way to avoid it would involve a custom memory management layer for these message objects. Even if that could be made efficient, it adds unnecessary complexity and risks new bugs. So losing a tiny number of bytes when your DLL gets unloaded (maybe a couple of hundred bytes per run of the host) is the pragmatic option.

6

Jules,

I just bumped into this and I was wondering if it is possible to somehow put a debug message on the console that says: "If you see memory leaks after THIS line, don’t worry about them."
The problem is that it becomes impossible to know if a memory leak was yours, or juce’s “standard memory leaks” ahum.

  • bram
7

I can’t really think how that’d be possible…