|
From: Michael L. <in...@pa...> - 2003-05-14 02:37:31
|
I am at a loss as to how to use valgrind. I have read the manual and a h= owto. =20 Using this command=20 export GLIBCPP_FORCE_NEW=3D1; valgrind --skin=3Dmemcheck --leak-check=3Dy= es=20 --show-reachable=3Dyes --logfile=3Ddebug.out --suppressions=3Dxfree-3.sup= p=20 --suppressions=3Dxfree-4.supp --suppressions=3Ddefault.supp=20 --suppressions=3Dglibc-2.2.supp src/.libs/lt-myapp My application produces hundreds of lines looking like =3D=3D26316=3D=3D 216 bytes in 21 blocks are still reachable in loss reco= rd 77 of 124 =3D=3D26316=3D=3D at 0x40160989: malloc (in /usr/lib/valgrind/valgrind= =2Eso) =3D=3D26316=3D=3D by 0x40B33B2F: __GI___strdup (in /lib/libc-2.3.1.so) =3D=3D26316=3D=3D by 0x40F5C37A: resolve_object (in /usr/X11R6/lib/lib= X11.so.6.2) =3D=3D26316=3D=3D by 0x40F5BF7C: _XlcDynamicLoad (in /usr/X11R6/lib/li= bX11.so.6.2) =3D=3D26316=3D=3D=20 What do I do with this stuff? It looks like it comes from an X11 library= but=20 the command line includes suppressions for X11. Why isn't X11 output=20 suppressed? Where do I get a suppressions file for Qt? Thanks. -- Michael |
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 07:41:10
|
On Tue, 13 May 2003, Michael Labhard wrote: > I am at a loss as to how to use valgrind. I have read the manual and a > howto. Using this command > > export GLIBCPP_FORCE_NEW=1; > valgrind > --skin=memcheck Memcheck is the default skin, so this flag is unnecessary > --leak-check=yes > --show-reachable=yes Don't use --show-reachable=yes and you won't the the "still reachable in loss record" messages below; they're not so important, they show memory that your program could have freed (it's still reachable via some pointer) but didn't bother to. > --logfile=debug.out > --suppressions=xfree-3.supp > --suppressions=xfree-4.supp --suppressions=default.supp --suppressions=glibc-2.2.supp default.supp is used as the default suppression file so you don't need to specify it. It's constructed at ./configure time from the relevant xfree/glibc/linux .supp files, so you don't need to mentiont them either. > src/.libs/lt-myapp > > My application produces hundreds of lines looking like > > ==26316== 216 bytes in 21 blocks are still reachable in loss record 77 of 124 > ==26316== at 0x40160989: malloc (in /usr/lib/valgrind/valgrind.so) > ==26316== by 0x40B33B2F: __GI___strdup (in /lib/libc-2.3.1.so) > ==26316== by 0x40F5C37A: resolve_object (in /usr/X11R6/lib/libX11.so.6.2) > ==26316== by 0x40F5BF7C: _XlcDynamicLoad (in /usr/X11R6/lib/libX11.so.6.2) > ==26316== > > What do I do with this stuff? It looks like it comes from an X11 library but > the command line includes suppressions for X11. Why isn't X11 output > suppressed? Where do I get a suppressions file for Qt? If you look in any of the .supp files, you'll see many suppressions for individual errors. These have been added as they were encountered. They should cover most X11 errors people get, but we may have missed some, or your machine might have an unusual configuration that means some errors are getting through. You can write your own suppressions; the manual currently doesn't explain how to very well, it would be easier to check out the CVS HEAD (from sourceforge.net) and use the --gen-suppressions feature to automatically generate suppressions (the feature isn't in 1.9.6). But first, just try "valgrind --leak-check=yes <program>", see how that works. N |
|
From: Olly B. <ol...@su...> - 2003-05-14 11:34:57
|
On Wed, May 14, 2003 at 08:41:06AM +0100, Nicholas Nethercote wrote:
> But first, just try "valgrind --leak-check=yes <program>", see how that
> works.
On a slightly tangential note, if your program is built using libtool
(as Michael's was, judging by the program name "src/.libs/lt-myapp") then
running the actual binary in .lib may not work. The most reliable way
to run it under valgrind would be:
libtool --mode=execute valgrind --leak-check=yes src/myapp
This lets libtool take care of any messing around with environmental
variables and the like that is required to get the program to run
before it has been installed.
The only wrinkle is that --mode=execute seems to have problems with
passing arguments to valgrind or the program in libtool 1.4.2 (you can
set VALGRIND_OPTS to pass options to valgrind). I've had no such
problems with libtool 1.5.
Cheers,
Olly
|