Thread is causing memory leaks

Hi,
I have a thread component in my plugin that was causing a memory leak whenever I closed my app through the ‘Local Windows Debugger’ in VS. As suggested in the JUCE module where the exception was thrown, I changed my code so that my component was used a scoped pointer and now when I close my app in VS, I don’t get the same exception thrown, but the debugger output prints:
Detected memory leaks!
Dumping objects ->
{1365142} normal block at 0x0000026A55704810, 7 bytes long.
Data: <C:\bb\b> 43 3A 5C 62 62 5C 62
Object dump complete.
The program ‘[8572] BIAB.exe’ has exited with code 0 (0x0).

In another forum, Jules explained that these small memory leaks should not effect the performance of the plugin, and that they can go unchecked, so I am wondering if there is a difference between not using a scoped pointer and getting the exception thrown or using a scoped pointer and having the debugger output show that memory is still being leaked. I’m not exactly sure how to handle any of this. I have made sure to stop all threads in my destructor but I still don’t understand what I could do to fix this if needed.

I don’t know which thread you’re talking about, but it sounds like you misunderstood it.

I’ve never said that leaks can be ignored if they’re small. That’d be bad practice.

But this particular leak is just a side-effect of a Message object sitting on the message queue at the moment when your plugin was deleted. That means that the message never gets delivered, so its payload isn’t deleted.

As I’ve explained on the (many!) other threads where I’ve talked about this, it’s not possible to force the message queue to be flushed at shutdown, and leaking a harmless few bytes on shutdown doesn’t justify the extra runtime overhead of other, more expensive object tracking mechanisms that would be the only way to avoid it.

TL;DR: No, don’t ignore small leaks… except for this one!

2 Likes