Recording Program Errors with valgrind

453

Option

What It Does

-e trace=file Forces strace to trace functions that expect a filename argument (this includes functions like open, unlink, and so on). Use this option to see which files a program uses.

-e trace=network Displays all network-related system calls.

-p process-ID Attaches strace to a running process, identified by process-ID. (You must have the proper privileges to use this option.)

ltrace has similar options, listed in Table 59-2.

TABLE 59-2: HANDY LTRACE OPTIONS

Option	What It Does
-f	Forces ltrace to trace child (and
	grandchild, great grandchild, and
	so on) processes spawned by the
	program you’re tracing.
-S	Displays system calls (similar to
	strace) as well as calls to functions
	defined in shared libraries.
-C	Demangles the name of each C++
	function. (C++ function names are
	mangled by the C++ compiler, mak-
	ing them difficult to read without
	special treatment.)
-s size	This option tells ltrace to print, at
	most, size characters when dis-
	playing string arguments. (The
	default value is 32, and that may be
	too short for some programs.)
-n indent	Indents nested function calls by
	indent spaces. (This option makes
	it easier to read complex logs.)
-e function1,	Traces only calls to the named
function2,...	functions.
-e !function1,	Forces ltrace to ignore calls to
function2,...	function1, function2, and so on.
-l library	Traces calls to functions defined in
	the given library. (For example, to
	see calls to the libz compression
	library, use the option -l /usr/
	lib/libz.so.1.)

That last option (-l library) is bit tricky because you have to know the complete pathname of the library that you’re interested in. Use ldd to find out which shared libraries are used by a particular program. For example, to find the shared libraries required by wget, use the following command:

$ ldd $(which wget)

libssl.so.4 => /lib/libssl.so.4 libcrypto.so.4 => /lib/libcrypto.so.4 libgssapi_krb5.so.2 => /usr/lib/

libgssapi_krb5.so.2

libkrb5.so.3 => /usr/lib/libkrb5.so.3 libcom_err.so.2 => /lib/libcom_err.so.2 libk5crypto.so.3 =>

/usr/lib/libk5crypto.so.3 libresolv.so.2 => /lib/libresolv.so.2 libdl.so.2 => /lib/libdl.so.2 libz.so.1 => /usr/lib/libz.so.1 libc.so.6 => /lib/tls/libc.so.6 /lib/ld-linux.so.2 => /lib/ld-

linux.so.2

Recording Program Errors with valgrind

Sometimes, buggy code is just, well, buggy. You can’t get a program to run properly, and you’ve done everything you can to ensure that the configuration and environment are correct. Time for another tool.

Unless you’re willing to read through the source code, compile your own copy, and get down and dirty with a debugger, the best thing you can do is to gather information for the developers.

valgrind is a programmer’s dream tool. valgrind runs your program and watches for programming errors such as the use of uninitialized memory, use of invalid memory regions, and memory leaks.

The valgrind package is not included with most distributions, but you can easily find valgrind RPM packages on the Web. (We found one at dag.wieers. com/packages/valgrind.)

454 Technique 59: Troubleshooting Persnickety Programs

After you’ve installed valgrind, it’s easy to use. Just run your program as usual, but put valgrind at the beginning of the command line, like this:

$ valgrind xmms

When you valgrind a program, valgrind messages are sent to the standard error stream (which is usually connected to your terminal window), so they can get lost in the output from the program that you’re watching. You can redirect valgrind messages to a file with the --logfile=filename option:

$ valgrind --logfile=/tmp/xmms.vg xmms

valgrind works by running your program on a synthetic, software-only CPU and watching all memory references. If your program uses an invalid hunk of memory, valgrind complains.

Your program will run many, many times slower on the synthetic CPU than it does on the real CPU.

Listing 59-3 shows a few sample error messages that valgrind produced when we ran the xmms media player.

LISTING 59-3: VALGRIND’ING XMMS

Each message starts with a one-line description of the error encountered and then a stack dump that shows what the program was doing at the time the error occurred. (The ==10247== at the beginning of each line is the process ID of the program that you’re watching.)

Now that you have a collection of valgrind messages, what do you do with them?

If you’re a programmer and you’re interested in helping out the developers, read through the documentation at the valgrind Web site (valgrind.kde.org). You’ll find out how to connect valgrind to a source-code debugger like gdb.

If you’re not a programmer, find the Web site that deals with your program and search around for a mailing list or some other mechanism for reporting bugs. When you send in a bug report, include the valgrind log and as much information as possible about your environment (especially the version number of the program you’re using). You’ll be doing the developers a big favor by telling them exactly where the bug was encountered.

==10247== Syscall param write(buf) contains uninitialised or unaddressable byte(s)

==10247==	at 0x57FC48: __GI___libc_write (in /lib/libc-2.3.2.so)
==10247==	by 0xAEC7DF: (within /usr/X11R6/lib/libICE.so.6.3)
==10247==	by 0xAED58E: _IceTransWrite (in /usr/X11R6/lib/libICE.so.6.3)
==10247==	by 0xAE430A: _IceWrite (in /usr/X11R6/lib/libICE.so.6.3)
==10247==	Address 0x21CA45C is 12 bytes inside a block of size 1024 alloc’d
==10247==	at 0x992B00: calloc (vg_replace_malloc.c:284)
==10247==	by 0xAE141F: IceOpenConnection (in /usr/X11R6/lib/libICE.so.6.3)
==10247==	by 0xAD52B8: SmcOpenConnection (in /usr/X11R6/lib/libSM.so.6.0)
==10247==	by 0x80A156D: sm_init (in /usr/bin/xmms)

==10247==

==10247== Conditional jump or move depends on uninitialised value(s)

==10247==	at 0x1BA72E: (within /usr/lib/libgtk-1.2.so.0.9.1)
==10247==	by 0x1C28F6: (within		/usr/lib/libgtk-1.2.so.0.9.1)
==10247==	by	0x1C3895: gtk_marshal_BOOL__POINTER (in /usr/lib/libgtk-1.2.so.0.9.1)
==10247==	by	0x18E0F9: (within	/usr/lib/libgtk-1.2.so.0.9.1)