|
From: Jaskaran S. <jas...@pe...> - 2005-10-13 14:22:13
|
Hi, 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. Regards, Jaskaran |
|
From: Nicholas N. <nj...@cs...> - 2005-10-15 16:50:21
|
On Thu, 13 Oct 2005, 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. You can invoke the leak checker at any time by using the VALGRIND_DO_LEAK_CHECK and VALGRIND_COUNT_LEAKS client requests. See 3.7 in the manual. --- On this note: we regularly get questions like this from Valgrind users who want to use Valgrind for unit testing. It would be great to have something in the manual and/or the FAQ about how to set this up. If someone who has set up such a system is willing to write a short description of how it works, that would be very useful. Nick |
|
From: <ape...@ni...> - 2005-10-17 17:34:06
|
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 |
|
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 > |