Hey snowman,
I'm assuming valgrind is already
installed on your system. If not you should be able to install it with
yum.
To run valgrind first "cd" to where the "leak"
executable is. Run the following command, which assumes that valgrind
is in your path:
valgrind --tool=memcheck --leakcheck=full --show-reachable=yes --error-limit=no --log-file=dump ./leak <gpib device> <gpib address>
You
should start to see the normal output of the application. Let it run
for a few seconds (30 seconds or so) and then hit CTRL-C. The
application should write a line of text that reads "Going down. The
count is n". Make note of "n".
In your directory you should
now have a plain-text file called dummy.<pid>. Open it up using
your favorite editor. It takes a bit to understand what valgrind is
telling you but the part you are interested in is near the bottom. It
should look something like this:
==3097== 1,736 bytes in 62 blocks are definitely lost in loss record 9 of 9
==3097== at 0x4004405: malloc (vg_replace_malloc.c:149)
==3097== by 0x40BD412: (within /usr/local/natinst/nipal/lib/libnipalu.so.1.11.0)
==3097== by 0x4118C24: _memNewUsingCRT(unsigned long, tMemAllocationFlags, long*) (in /usr/local/natinst/nipal/lib/libnipalu.so.1.11.0)
==3097== by 0x402FB17: (within /usr/local/natinst/ni4882/lib/libgpibapi.so.2.5.1)
==3097== by 0x402F9EE: (within /usr/local/natinst/ni4882/lib/libgpibapi.so.2.5.1)
==3097== by 0x402F8F8: (within /usr/local/natinst/ni4882/lib/libgpibapi.so.2.5.1)
==3097== by 0x402D930: (within /usr/local/natinst/ni4882/lib/libgpibapi.so.2.5.1)
==3097== by 0x40280F7: (within /usr/local/natinst/ni4882/lib/libgpibapi.so.2.5.1)
==3097== by 0x4061D1C: ibdev (in /usr/local/natinst/ni4882/lib/libgpibapi.so.2.5.1)
==3097== by 0x80487C1: proc(void*) (in /home/jmay/driver/leak/leak)
==3097== by 0x5943CB: start_thread (in /lib/tls/libpthread-2.3.4.so)
==3097== by 0x3FC1AD: clone (in /lib/tls/libc-2.3.4.so)
What
this block is telling you is that 1736 bytes were allocated by "malloc"
but never free'd. You can follow the functions by going backwards.
"malloc" was called by "_memNewUsingCRT" which was called by a function
at 0x402FB17, etc. If you track back you can see that the chain was
started by a call to "ibdev" in the function "proc".
If you
divide the bytes allocated (1736) by 28 you should get "n".
With
minimal effort you should be able to modify the leak application so
that it doesn't use threads and then re-run valgrind. You'll notice
that the you won't see leak then.
Here's a link I found that does a way better job explaining
valgrind's output which may helpful.
Again, I do
appreciate you taking the time and if I can help in any way let me know.
--twotymz
