|
From: Bart V. A. <bva...@ac...> - 2010-06-08 15:37:24
|
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. |