|
From: Johan B. <jb...@gm...> - 2010-06-08 16:30:04
|
Ah, sorry I wasn't clear enough. I'm trying to solve it for objects that have a long lifetime, where the stacktrace for the original allocation isn't very helpful in tracking down where the reference was leaked. I've seen people solve the same problem by having a sentinel variable in the addRef()/releaseRef() functions, allowing you to either print a stacktrace (or break into a debugger) whenever a reference counting operation is done on the object you are debugging. In my particular case, we had an object cache: ObjectCache::getOrCreate(ID); which would do some magic and either allocate a new object, or return you the cached one for ID with refcount +1. At the end of execution, valgrind would tell me that I was leaking objects, but I could only see the allocation point, which wasn't enough to track down the actual leak. -Johan On Tue, Jun 8, 2010 at 5:37 PM, Bart Van Assche <bva...@ac...> wrote: > On Tue, Jun 8, 2010 at 5:25 PM, Johan Björk <jb...@gm...> wrote: >> >> I've been working with a C++ projects with many refcounted objects, >> and I ended up spending a lot of time trying to track down reference >> leaks. To aid my debugging, I wrote some very quick and dirty memcheck >> macros to help me debug. >> >> /* Create refcounted object */ >> VALGRIND_CREATE_REFCOUNTED(address,initial_value) >> /* delete refcounted object */ >> VALGRIND_DELETE_REFCOUNTED(address) >> I added this one to deal with cases where an application force deletes >> a reference counted object, even though the reference count is >0. >> (Sigh...) >> /* Modify the refcount for an object */ >> VALGRIND_MOD_REFCOUNT(address,val) >> >> I modified memcheck to store the stacktrace at each invocation of the >> MOD_REFCOUNT macro. (Avoiding duplicates by comparing the ecu, storing >> a count for each unqiue stacktrace) >> For each alive MC_Chunk object at the end of execution, I check if >> refcount != 0, and print the stacktraces, allowing (easier) manual >> inspection to locate where a reference is leaking. >> >> While the method is rather crude (Once the number of unique >> stacktraces go above 10, it's a lot of work to match the >> 'corresponding' ones), it helped me incredibly to find the leaks in my >> app. >> >> Anyone know if there has been something similar developed before? > > A straightforward technique is to allocate refcounted objects on the heap, > such that memcheck's leak checker can dump the allocation call stack of > objects that have been allocated but not deallocated. Or did I miss > something ? > > Bart. > |