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.

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 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.