On Saturday, August 14, 2010, Ivan Godard wrote: > Our application does significant work in the destructors that are run > after main() exits. I'm getting "definite leak" reports for allocations > that are stored into global variables during this work and not > subsequently overwritten. This suggests that valgrind does its leak > "reachable" analysis at the end of main,
No .. it does it when the last thread exits. When that happens, V then tries to run glibc's __libc_free() function to free any resources that libc is still sitting on (including memory), and then the leak detector runs. J > but before all global > destructors have been run, and so can lose track of post-main allocation > anchors. There are well-known similar issues in the ordering of > destructors and at_exit(). > > Is this in fact the way leak analysis is done? Or is there some other > issue that can give false leaks in these cases? > > And is there a workaround? > > Valgrind is 3.4.1, x86 Linux. Thank you. > > Ivan > > --------------------------------------------------------------------------- > --- This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Valgrind-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/valgrind-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
