When closing down a 64 bit Cubase project that is running a Juce 64 bit plugin I get the following Leaked objects message. Is this my fault? I don’t believe I ever explicitly create any messages of these kinds.
The thread ‘Win64 Thread’ (0xb88) has exited with code 0 (0x0).
The thread ‘Win64 Thread’ (0xd90) has exited with code 1 (0x1).
The thread ‘Juce Timer’ (0xa70) has exited with code 0 (0x0).
*** Leaked objects detected: 2 instance(s) of class CallbackMessage
Cubase5.exe has triggered a breakpoint
*** Leaked objects detected: 3 instance(s) of class Message
Cubase5.exe has triggered a breakpoint
Detected memory leaks!
Dumping objects ->
{335345} normal block at 0x000000001ED7CA40, 56 bytes long.
Data: < ) > A8 29 0C F0 FE 07 00 00 01 00 00 00 CD CD CD CD
{31678} normal block at 0x0000000018F57720, 80 bytes long.
Data: < > 88 82 0B F0 FE 07 00 00 01 00 00 00 CD CD CD CD
{31674} normal block at 0x0000000018F57440, 80 bytes long.
Data: < > 88 82 0B F0 FE 07 00 00 01 00 00 00 CD CD CD CD
Object dump complete.
Yeah, this gets mentioned very often… I think I might actually just remove the leak detector from that class in the plugin build.
Because the host is in charge of the event queue, it’s quite possible that the plugin posts one of these messages, and then gets deleted before the event is delivered - so inevitably the event is lost. Not a big deal, they’re very small and only one or two will be lost each time the plugin is unloaded from memory.
I am getting a lot of these messages when I run my plugin in the Juce VST host. Am i not implementing some callback somewhere perhaps ?
*** Leaked objects detected: 200 instance(s) of class CallbackMessage
Plugin Host.exe has triggered a breakpoint
*** Leaked objects detected: 201 instance(s) of class Message
Plugin Host.exe has triggered a breakpoint
Detected memory leaks!
Dumping objects ->
{207110} normal block at 0x065A1288, 56 bytes long.
Data: < > 94 85 8D 05 CD CD CD CD 01 00 00 00 CD CD CD CD
etc
I’m not knowingly using the CallbackMessage anywhere in my code. How can I determine which object these callback messages are related to ?
I’m not using the latest tip but I don’t think this is something in the framework. I think I had something similar once but can’t recall what it was that leaked.
I’m not sure, whether this is the best way, but what I do is removing components/objects (with tags like "//LEAKTESTSLIDER1 " that can be undone easily with a replace) until the leak dissapears. Best to start with the editor (return false in hasEditor() and 0 in createEditor()).
I’d expect to see a couple of undelivered messages get leaked sometimes, but 200 is a bit much! Sounds like you might be leaking them in your own code, or maybe you have a huge number of AsyncUpdater objects constantly pumping out these messages?
