guy keren wrote:
> all i can say is, if you're programming in C or C++, on a platform that
> valgrind supports, and you don't use valgrind - you're shooting
> yourselves in the leg. nothing comes even close to valgrind in the list
> of malloc debugging libraries - because valgrind is not a
> malloc-debugging library - it's a code instrumentation tool, and thus
> has much more control on the program being debugged.
>
> if you haven't tried it - try it now.
>..
OK, I did.
First, I should say that I also tried dmalloc and efence
(ElectricFence), so let me give my impressions of them.
dmalloc can be linked to precompiled object files and seems to detect
things that would otherwise segfault or sometimes just be an undetected
leak. It needs to be "programmed" by calls to a /usr/bin/dmalloc. Don't
know where it saves it's settings. There are maybe a couple dozen
settings, including enabling a logfile. I find the instructions and,
more important (I think), the logfile messages a little cryptic,
although I'm sure it should be useful with some effort and practice.
Some errors, it seems, can only be detected by an optional "#include
dmalloc.h". The dmalloc.h also enables source file line-number
references in the logfile messages, which seems nice.
aside on mtrace (which I thought was oversimple/unreliable):
before I forget, mtrace settings were taken from environment variables
I didn't spend a lot of time on efence, but it did seem to work well and
without much preparation. efence works without any need or optional
includes, just a linked libefence, like dmalloc. Efence uses environment
vars for settings like mtrace. BUT, efence needs to be run via a
debugger. First impression is that it does some things quite nice, but
misses some of the harder ones (like wild pointer). Maybe I just didn't
pursue the right option settings.
One of the reasons I didn't spend more time is that in Perens' own words,
"..Purify does a much more thorough job than Electric Fence, and does
not have the huge memory overhead. Checkergcc, a modified version of
the GNU C Compiler that instruments all memory references, is available
on Linux systems and where GCC is used. It performs some of the same
tasks as Purify, but only on code that it has compiled."
(Also, i was anxious to get to valgrind..)
Valgrind is good. Valgrind is great. Thanks GK for the kick. I've wanted
to look at it for a while, but thought it must be pretty complicated.
It seems that VG _is_ a pretty big package, and has *lots and lots* of
capabilities (that could be confusing), but is done so nicely that one
can ease into it with very little pain.
It requires no compile changes or special linking. It runs your
executable in a "synthetic CPU". What is especially neat is that the
error report ends with hints on what options to add to get more info.
For example
valgrind ./myprog
gives
..<nice quite readable error message stuff>, followed by
Use --leak-check=full to see details of leaked memory
It even catches segfaults from writes to wild pointers. It reports lib
routine calls and source functions (unless you run strip).
It has what looks like a nice man pae, and a big manual, which I'll have
to put on my reading list, but the neat thing is that there are simple
recipes, and default operating mode does quite nicely at reporting most
bad stuff (in *understandable* language).
Downsides: in the default ('Memcheck') mode,
"..Your program will run much slower (eg. 20 to 30 times) than normal,
and use a lot more memory."
Regards,
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
