Using Valgrind to track memory bugs
Special thanks for Dan Kegel for his work and suggestions for using this tool with the QA project.
The free tool Valgrind (like the commercial tool Purify) runs programs in a special way that is twenty times slower, but catches wild pointer and uninitialized memory bugs before they can do any damage. It's really a wonderful tool for anyone trying to find that kind of bug in a complex program. Its main drawbacks are slowness and limited platform support (it only runs on x86 linux). Julian Seward, the author of Valgrind, has a nice presentation about it; it's online at
http://ooo.ximian.com/valgrind/valgrind.html
You should use Valgrind when there's a hang or crash that's hard to reproduce in gdb, when you are trying to track down a particular bug that you think might be a memory corruption, or if you are running through automated regression tests and want to make darn sure there are no hidden bugs. If Valgrind is the only way to notice a problem, please add keyword 'valgrind' to the issue.
Here are canned queries that may be of interest:
| Issues with keyword 'valgrind' | These are issues where valgrind was definitely helpful in finding a problem | |
| Issues that mention Valgrind |
Installing Valgrind
To install Valgrind, download the latest source from http://developer.kde.org/~sewardj and perform the standard Unix source compilation procedure:bash$ tar -xjvf valgrind-20030725.tar.bz2 bash$ cd valgrind-20030725 bash$ ./configure bash$ make bash$ make install
To run OpenOffice 1.1 with valgrind, run the commands:
Please note, set the "bin" variable to your OOo.org installation directory
bash$ bin=/opt/OpenOffice.org1.1/program bash$ LD_LIBRARY_PATH=$bin bash$ valgrind $bin/soffice.bin
This will output warnings whenever it detects strange memory accesses. If you get too many "uninitialized memory" warnings, add the option --skin=addrcheck:
Please note, set the "bin" variable to your OOo.org installation directory
bash$ bin=/opt/OpenOffice.org1.1/program bash$ LD_LIBRARY_PATH=$bin bash$ valgrind --skin=addrcheck $bin/soffice.bin
addrcheck doesn't check for uninitialized memory, and runs about twice as fast as the default setting.
Note: there are many minor bugs in the standard system libraries that only recently came to light thanks to tools like Valgrind, so Valgrind shows a fairly large number of false positives. For instance, closedir() in glibc contained an illegal call to pthread_mutext_destroy that was only fixed very recently (in glibc-2.3.2), so expect to see warnings of that sort if you're not using the latest glibc.
When valgrind logs an error, it saves only four lines of stack backtrace. You can increase this number with the commandline parameter --num-callers. You should increase this to 100 to get enough information for application developers to fix their problems.
Making OpenOffice More Valgrindable
Valgrind works fine on unmodified executables, but if you're building OpenOffice from source, there are three things you can do to make an OpenOffice executable that's more Valgrind-friendly:
Compile libsal.so.3.1.0 with -DFORCE_SYSALLOC so Valgrind can put a guard around all allocations
Compile all modules with -g so Valgrind can give better stack dumps
Compile all modules with -O0 (disables optimization) - supposedly reduces false positives
Alternately, if you don't want to build from source, and you're testing OpenOffice1.1rc1 on a glibc-2.3.2-based system, you can replace your libsal.so.3.1.0 with this copy of libsal.so.3.1.0, which was compiled with -DFORCE_SYSALLOC under glibc-2.3.2. Doing this lets you find quite a few more problems in OOo.
Using gdb with Valgrind
You can have valgrind launch gdb when it runs into an error; then you can do all the backtracing and printing of variabls you like. To do this, add the option --gdb-attach=yes. This doesn't work quite right, since OpenOffice appears to close stdin. Here's one way to work around that: 1. Create a little script named ~/rungdb containing #!/bin/sh XAUTHORITY=~/.Xauthority DISPLAY=127.0.0.1:0.0 /usr/X11R6/bin/xterm -e gdb "$@"
Be sure to chmod +x ~/rungdb. The script is started without the normal environment variables, so you need to explicitly set any that are needed. The above is for Red Hat Linux 8.0. If the crash you're seeing happens to happen while the X display lock is held, you'll probably want to set DISPLAY to some other host's X display... that actually happened to me once.
Then run OpenOffice with the command #!/bin/sh bin=/opt/OpenOffice.org1.1Beta/program LD_LIBRARY_PATH=$bin valgrind -v --skin=addrcheck \ --gdb-attach=yes --gdb-command=~/rungdb \ $bin/soffice.bin
That will pop up an xterm with a gdb inside it every time you say 'yes' when valgrind asks whether to start gdb. Note that all you can do in that gdb is get a backtrace; you can't continue the program. You must quit gdb before valgrind will continue.
