Leakdetecting failing me (?)


#1

Hi,
I’m a big fan of the built in leak detection of juce, but all of a sudden (?) it has started to fail me. I think… Or am I suffering from some sort of memory corruption?

  • On quit, I get a report from VS2010 that there was a bunch of memory leaks. I can roughly track them to a certain class.
  • I don’t get any indication from juce that anything is leaked.
  • I seem to be able to track all destructors in the so called leaked objects.
  • When deliberately leaking a juce object, juce does properly report it.

All of the above indicate that VS2010 is giving me false positives, but I don’t recall seeing these earlier.
Does anyone have a tip of how I can track down the problem/actual problem? I’m at a loss!

Supposedly, on quit, juce is reporting leaks before VS2010, so something must be wrong, which juce doesn’t see?

Thanks in advance, Michael


#2

The juce Leak Detector has one flaw. It depends on the order of destruction of the “LeakCounter” object that belongs to each class.

Normally, this is not a problem if your application does ALL of its new / delete operations within the JUCEApplication::initialise and JUCEApplication::shutdown.

However, if you are dynamically creating singletons - user defined objects with static storage duration in different translation units (i.e. source files) - and these objects refer to each other, you can enter a situation where the destructor for a LeakCounter of a global object allocated via operator new is called before all instances of the object are gone.

So, let me ask you, are you creating leak checked objects using operator new, and storing the pointers in global variables?

I had this problem myself and my solution was to

  • reference count all of my persistent singletons, and keep them in a linked list.
  • roll my own leak checker that keeps a linked list of counters to check on program exit
  • in the destructor of just one object at global scope, I do the following:
  1. release each singleton in the list of persistent singleton references
  2. check for leaks for each counter in the list of leak counters

By doing 1) before 2) this order of destruction issue is resolved.


#3

Hi Vinn,
This is really embarrassing. I found the problem. When ending a debug session VS2010 only reports the first few bytes in the leak, and looking at those bytes I was under the impression that the leaked block where object data, but in fact it was just ordinary memory blocks created with “new”. The contents was suspiciously similar to what would be found in some objects, but in fact it was not so.

False alarm - the fault was in my code. (Quite obvious too…)

Thanks for your help though. It can be helpful in other situations.