Jump to content
  • Advertisement
Sign in to follow this  
wqking

Using Valgrind as recursive testing tool, want your experience

This topic is 2399 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

--- The word "recursive" in the subject should be regression.

Currently I am using the great Valgrind as a kind of regression testing tool.
My idea is after I changed the code, run Valgrind to see if anything wrong, such as any memory leaks.

Now I only use the option --leak-check=yes in Valgrind.

Because I'm new to Valgrind, I want to hear your experience/opinions on,

1, Is --leak-check=yes enough for memory check?
I'm not sure. There are several other options in Valgrind, such as --show-reachable.
Here memory check, I mean not only memory leak, but also such like double free, wild pointer, etc. ANY kind of memory problem.

2, Beside memory check, what can Valgrind help us in real application? CPU Cache profile? Thread?
Though now I only use the tool on a library without cache issue or multiple thread, it's good to know how you use Valgrind.

3, Did you integrate Valgrind to any auto test process?
Now I run Valgrind in standalone, not in any auto test process yet.

I felt so happy on using this great tool, it helped me to find several tricky memory problem.
If you can share your experience on it, that will be more great. :) Edited by wqking

Share this post


Link to post
Share on other sites
Advertisement
I have no idea what you mean by "recursive".

We use Valgrind all the time for testing a database server we develop. We generally use memcheck with leak-check=full and sometimes run drd with certain options as well. Memcheck will check for memory leaks (it's kind of trivial to do so), but I believe leak-check will get you very useful output about what allocated a given block. Memcheck will catch double frees, wild pointers, use of uninitialized memory, etc etc etc, and the quality of the output is improved with leak-check. (Or so I presume it's improved. I haven't really done any runs without --leak-check=full so I don't really know.) Regarding other options: We don't have --show-reachable set, probably just because memory leaks are very rare, and we've never needed to debug a reachable memory leak very closely. If somebody snuck into our test scripts and added the option, I don't think we'd turn it off. I don't know about the other options, but the documentation seems to be generally pretty clear.

One indirect benefit of running valgrind is that it makes the CPU performance of your program really slow. As a result, this tends to uncover race conditions. We don't really use valgrind for profiling, we use oprofile for serious profiling, but right now the only reason we care about CPU performance is to make the valgrind tests run faster, and I've used the valgrind profiling tool for that purpose (just because it was a command line argument away). Almost all of our tests are run under valgrind+debug mode or release mode without valgrind, with a few core tests run under other combinations of options.

Share this post


Link to post
Share on other sites
Maybe recursive is not a proper word.
I mean just to test to ensure any new changes won't break existing code.

Share this post


Link to post
Share on other sites

Maybe recursive is not a proper word.
I mean just to test to ensure any new changes won't break existing code.

I think you mean 'regression' testing.

Share this post


Link to post
Share on other sites

[quote name='wqking' timestamp='1319964971' post='4878518']
Maybe recursive is not a proper word.
I mean just to test to ensure any new changes won't break existing code.

I think you mean 'regression' testing.
[/quote]

Ah, yes yes, thank you for correct me.
I will edit my original post.

Share this post


Link to post
Share on other sites


1, Is --leak-check=yes enough for memory check?
I'm not sure. There are several other options in Valgrind, such as --show-reachable.
Here memory check, I mean not only memory leak, but also such like double free, wild pointer, etc. ANY kind of memory problem.


I recommend you also add "--show-reachable=yes".

Yes, I highly recommend running valgrind as a regular part of your development test cycle. It can be automated. There are scripts floating around that can parse valgrind output and, say, format an HTML page with results.

Share this post


Link to post
Share on other sites

[quote name='wqking' timestamp='1319952450' post='4878446']
1, Is --leak-check=yes enough for memory check?
I'm not sure. There are several other options in Valgrind, such as --show-reachable.
Here memory check, I mean not only memory leak, but also such like double free, wild pointer, etc. ANY kind of memory problem.


I recommend you also add "--show-reachable=yes".

Yes, I highly recommend running valgrind as a regular part of your development test cycle. It can be automated. There are scripts floating around that can parse valgrind output and, say, format an HTML page with results.
[/quote]

In addition, I use the --track-origins option extensively. It is very nice.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!