Some enhancements for more control

Oct 13, 2010 at 9:05 PM
Edited Oct 13, 2010 at 11:16 PM

Having a memory tracker in use since my Amiga system, to SGI, to PC, I've upgraded it as needed over almost 20 years. With VC2008, I get into so much trouble trying to mix STL's allocators and my own new() overloading that I searched again on the net and found VLD. Seems excellent sofar (day 1 of use).

I do miss some functionality that would be most helpful to developers, or at least I have in the past (and need now). Having VLD only output leaks at the program's exit seems a bit unsubtle; I want more control.

My way of debugging into more detail:

- init program

- when any memory leaks are detected at all, I want to see which part of the code seems responsible, so I did this always:

  MarkAllLeaksAsRead();      // all current allocations are probably ok; don't want to know about them

  DoComplexTask();          // allocates & frees, should be memory-neutral (no leaks)

  ReportAllNewAllocations();        // shows any allocations that were NOT freed in DoComplexTask().


You may wonder if that is necessary; well, I'm building a race simulator where you allocate a lot of stuff, then go into a race, exit it. , start another race etc. Between races, I want everything to be freed when I get back in the menu. With VLD, I cannot yet zoom in on a specific piece of code and see what leaks that part may have.

I'm now making:

- blockinfo_t gets a 'flags' field with a bit that stated 'REPORTED' or not. At ReportLeaks() time, it will skip reporting of already reported leaks; I have several hundreds to thousands of allocations active while running, and those are NOT specifically leaks yet.

- SetReportOptions gets an extra 'cbReportFunc' argument to allow a callback function like: void myCallBack(char *s){ ... }. I have my own set of debugging outputs (UDP network for one) and I want to route messages my way. No use for the debugger output or files; I can take care of all that when just getting any messages from VLD in my own functions. (this is now already working).


Not sure if I could patch things back up, but it seems like only a line or 30 of code in all, so I might just post it here if people are interested. Through the years, I'm used to setting up small areas of code where I track down memory leaks. Doing it only at exit time is way too late and gives you trouble if you use a few C++ global variables.




Dec 20, 2010 at 11:31 AM

I second this. I have the exact same problem.