|
From: Philippe W. <phi...@sk...> - 2010-06-09 19:52:35
|
I suppose that the reference is an object for which constructors and destructors are automatically increasing or decreasing the reference count in the object pointed to by the reference. If that is the case, you could then make a very small allocation in the constructor, store the pointer in the reference object, and do the free in the destructor of the reference object. With this, the normal leak search of valgrind (using the --show-reachable) will show you the reference objects that have not been destroyed, with the stack trace showing the reference creation. In other words, the small allocated memory becomes the sentinel variable, but automatically tracked by memcheck. Philippe ----- Original Message ----- From: "Johan Björk" <jb...@gm...> To: "Bart Van Assche" <bva...@ac...> Cc: "valgrind-developers" <val...@li...> Sent: Tuesday, June 08, 2010 6:29 PM Subject: Re: [Valgrind-developers] Using memcheck to debug referencecounting errors 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. > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Valgrind-developers mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-developers |