|
From: Jaskaran S. <jas...@pe...> - 2005-10-18 10:21:48
|
Thanks people. The client request mechanism solves my problem for now. ~Jas ----- Original Message ----- From: <ape...@ni...> To: "Jaskaran Singh" <jas...@pe...> Cc: <val...@li...> Sent: Thursday, October 13, 2005 8:45 PM Subject: Re: [Valgrind-users] Valgrind API interface > On Thu, Oct 13, 2005 at 07:51:21PM +0530, Jaskaran Singh wrote: > > > Does valgrind provide a means of selectively turning heap checking ON and OFF programmatically ? > > > > Something like: > > > > HeapChecker.start(); > > doSomething(); > > HeapChecker.stop(); > > > > so that the generated report contains leaks, if any, in doSomething(); I am looking to integrate valgrind with my unit test framework but I do not want the complete test harness to run under valgrind as that can be prohibitive. > > I don't think valgrind lets you do specifically that. We made it work with > WvStreams unit tests, however, by comparing the *number* of "definitely > lost" leaks before and after doSomething() by using the valgrind API > function that checks for and feeds you that number. Then we consider it a > failed unit test if the number has changed. > > Note that "still reachable" and "possibly lost" blocks are meaningless > except at the very end of the program (think global constructors), so we > don't use those numbers. > > The API calls you suggest might still be useful if added to valgrind: > allocated blocks could be tagged with an "I care about this block" flag. If > they were allocated after a HeapChecker.stop(), we don't care about this > block, so it won't be counted when checking the final memory leak count. > > However, in my experience, it's best to just fix all your memory leaks: it's > not so great if your unit test framework (outside of doSomething()) is > itself leaking memory. > > Have fun, > > Avery > |