valgrind questions

Matthias Andree matthias.andree at gmx.de
Sun Jan 12 01:40:42 CET 2003


David Relson <relson at osagesoftware.com> writes:

> Greetings,
>
> I have a copies of bogofilter, bogoutil, and bogolexer that include a
> statically linked copy of db3.3 (built by me).  Running valgrind with
> these executables gives much more informative results than using than
> the standard shared library.
>
> Is anybody an expert with this tool and interpreting/using its outputs?
>
> The output Here's some of what I've seen/learned.
>
> For example, in bogoutil, dump_file() is calling printf() is callling
> strnlen() and therein lies an issue.  Here's the valgrind output for it
>
> ==11753== Invalid read of size 1
> ==11753==    at 0x402CBCCE: (within /lib/i686/libc-2.2.5.so)
> ==11753==    by 0x402A6342: (within /lib/i686/libc-2.2.5.so)
> ==11753==    by 0x804DD6A: dump_file (in /home/relson/filter/tst/bogoutil)
> ==11753==    by 0x804F023: main (in /home/relson/filter/tst/bogoutil)

This doesn't look too verbose, valgrind is usually capable of printing
source file and line. Has -fomit-frame-pointer been used to compile the
program? If so, remove. Have you used -g or -ggdb? Use -g. Try

CFLAGS="-pipe -g" ./configure --your-options && make clean && make all

Do not strip the executables. Do not use -s as any compiler option.

> Valgrind also prints the following message sets, which I don't
> understand (yet):
>
> ==11753==    by 0x4026F082: (within /lib/i686/libc-2.2.5.so)
> ==11753==    by 0x804DA71: strcpy@@GLIBC_2.0 (in
> /home/relson/filter/tst/bogoutil)
>
> ==11753==    Address 0x42C056FF is 0 bytes after a block of size 15 alloc'd
> ==11753==    at 0x4003BB2C: realloc (in /usr/lib/valgrind/valgrind.so)
> ==11753==    by 0x806DEA0: __os_realloc (in /home/relson/filter/tst/bogoutil)
> ==11753==    by 0x809DAB2: __db_retcopy (in /home/relson/filter/tst/bogoutil)
> ==11753==    by 0x809D925: __db_ret (in /home/relson/filter/tst/bogoutil)
> ==11753==    by 0x8092283: __db_c_get (in /home/relson/filter/tst/bogoutil)
> ==11753==    by 0x804DC25: dump_file (in /home/relson/filter/tst/bogoutil)
> ==11753==    by 0x804F023: main (in /home/relson/filter/tst/bogoutil)
> ==11753==    by 0x4026F082: (within /lib/i686/libc-2.2.5.so)
> ==11753==    by 0x804DA71: strcpy@@GLIBC_2.0 (in
> /home/relson/filter/tst/bogoutil)

Reading these two halves together tells you:

1. that some function within libc tried to read a character (size 1)
   from a place where it should not have read (invalid).

2. additional information on the place where the invalid read took
   place. In this case, some time before the invalid read, dump_file has
   had db's c_get realloc() memory, DB chose to allocate 15 bytes. The
   invalid read then read past the realloc()d buffer, and it tried to
   read the byte immediately after the buffer, "0 bytes after".

3. The first stack backtrace tells you how the invalid read came to be,
   and the second stack backtrace tells you how the memory was
   allocated.

HTH

-- 
Matthias Andree




More information about the bogofilter-dev mailing list