Comment 16 for bug 1247026

Revision history for this message
In , Matt (mattcbro) wrote :

(In reply to comment #8)
> Created attachment 82043 [details]
> A temporary bandage fix to ignore strlen() redirection for amd86 linux
> architecture
>
> By applying the patch, I could run valgrind on Debian GNU/Linux amd64
> 64bits) version.
> The patch basically disable's the request for catching the call to the
> native strlen()
> and monitor it with valgrind's internal version.
>
> Julian, it seems that, at least on Debian GNU/Linux amd64, valgrind does not
> bomb out even if strlen is not traced by memcheck. After all, gcc-4.8 which
> I use to compile mozilla's thunderbird seems to replace all calls to
> strlen() with an inlined version and so there is no loss (and no gain) by
> not redirecting the call to strlen().
>
> People's mileage may vary depending on
> - the OS version
> - the versions of the library (especially /lib64/ld-2.17.so,
> /lib/ld-n.nn.so,
> and friends.), and
> - the compiler used.
>
> I have patched 3.9.0 SVN version (obtained by svn command from the
> repository) and compiled it myself using the patch.
>
> Now that valgrind can run without having to change libc (which I was not so
> sure how to do easily) on my Debian GNU/Linux amd64, I have to figure out
> though why the following command results in crashing thunderbird :
> BAD: valgrind --trace-children=yes --smc-check=all-non-file
> --gen-suppressions=all --track-origins=yes --read-var-info=yes
> --malloc-fill=0xA5 --free-fill=0xC3 --leak-check=full --num-callers=50
> --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/cross-
> architecture.sup
> --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/i386-
> redhat-linux-gnu.sup --suppressions=$HOME/Dropbox/myown.sup
> --show-possibly-lost=no
> /REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/thunderbird-bin
>
> while the following command run thunderbird successfully
> GOOD:
> valgrind --read-var-info=yes --trace-children=yes --smc-check=all-non-file
> --malloc-fill=0xA5 --free-fill=0xC3 --leak-check=full --num-callers=50
> --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/cross-
> architecture.sup
> --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/i386-
> redhat-linux-gnu.sup --suppressions=$HOME/Dropbox/myown.sup
> --show-possibly-lost=no
> /REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/thunderbird-bin
>
> Note the addition of --gen-suppression=all on the BAD command line. It seems
> that
> valgrind itself is crashing, but the stacktrace shown is that of thunderbird
> (but without proper symbolic trace.) I will file a separate entry after more
> investigation.
>
> TIA

This patch was a big help to me, thanks. I can't develop without valgrind.

 It does expose an issue on Ubuntu/Debian 64 bit machines and maybe others. Is it reasonable to have no entry point for strlen(), which is an ANSI C library function?

It would certainly be 'easier' in some sense if valgrind moved to another means of detecting a library with proper debug symbols.