|
From: Christophe L. <chr...@st...> - 2011-02-18 16:11:34
|
Hi, With both releases 3.6.0 and 3.6.1, I have noticed that valgrind almost always segfault on my RedHat-4 x86_64 machine. It seems that it works when running a 32 bits program, and fails when running a 64 bits one. For instance: $ valgrind /bin/ls ==18112== Memcheck, a memory error detector ==18112== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==18112== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==18112== Command: /bin/ls ==18112== Segmentation fault (Obviously, /bin/ls works when not executed through valgrind ;-) $ file /bin/ls /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped $ valgrind /path/to/32bits/bin/ls [ls output is OK] What can I do to track down this problem, and maybe post a bug report with enough useful information? Thanks, Christophe. |
|
From: John R. <jr...@bi...> - 2011-02-18 16:39:54
|
> $ valgrind /bin/ls
> ==18112== Memcheck, a memory error detector
> ==18112== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==18112== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
> ==18112== Command: /bin/ls
> ==18112==
> Segmentation fault
>
> (Obviously, /bin/ls works when not executed through valgrind ;-)
As with any compiled binary program, run it under a debugger such as gdb
and display information at the time of signal:
$ gdb valgrind
(gdb) run /bin/ls ## add other command-line arguments here
[SIGSEGV]
(gdb) x/i $pc
(gdb) info reg
(gdb) x/12i $pc-0x20
(gdb) bt
(gdb) quit
Sometimes SIGSEGV is expected. So rather than 'quit', say 'continue'
and see if the continuation look reasonable.
Also as with any compiled binary program, the strace utility shows the
interaction with the operating system:
$ strace -f -o strace.out valgrind /bin/ls
Then look at the last few dozen lines of file strace.out.
The output from strace will show how many SIGSEGV were "intentional".
valgrind has some built-in debugging:
$ valgrind -d /bin/ls
Depending on what this shows, consider other debugging options that
are displayed by "valgrind --help-debug" which is hinted from
"valgrind --help".
As with all software, RTFM:
http://valgrind.org/docs/manual/manual.html
http://valgrind.org/support/bug_reports.html
which are linked from the very top level http://valgrind.org/
--
|
|
From: Julian S. <js...@ac...> - 2011-02-18 18:05:30
|
> $ valgrind /bin/ls > Segmentation fault Try "valgrind -v -v -d -d /bin/ls" and post the result to the list. Also make sure there is no confusion with any valgrind that might already be installed on the machine. J |
|
From: Christophe L. <chr...@st...> - 2011-02-21 18:07:44
Attachments:
log.execution
|
On 18.02.2011 19:04, Julian Seward wrote: > >> $ valgrind /bin/ls >> Segmentation fault > > Try "valgrind -v -v -d -d /bin/ls" and post the result to the list. > > Also make sure there is no confusion with any valgrind that might > already be installed on the machine. > > J > > Please find the log attached. I have made some progress: for some reason, I used to compile with -fPIC in CFLAGS. Removing it makes my valgrind work. I am compiling with GCC-4.4.4 on a x86_64 host. Christophe. |
|
From: Christophe L. <chr...@st...> - 2011-02-23 16:09:26
|
On 21.02.2011 19:07, Christophe Lyon wrote: > On 18.02.2011 19:04, Julian Seward wrote: >> >>> $ valgrind /bin/ls >>> Segmentation fault >> >> Try "valgrind -v -v -d -d /bin/ls" and post the result to the list. >> >> Also make sure there is no confusion with any valgrind that might >> already be installed on the machine. >> >> J >> >> > > Please find the log attached. > > I have made some progress: for some reason, I used to compile with -fPIC in CFLAGS. Removing it makes my valgrind work. I am compiling with GCC-4.4.4 on a x86_64 host. > > Christophe. I have understood why I didn't notice this problem before: since release 3.6.0, the top-level configure has changed CFLAGS="-Wno-long-long" into CFLAGS="-Wno-long-long $CFLAGS" such that the -fPIC which was present in my config.site CFLAGS is now propagated to all valgrind components. So... is it expected that compiling valgrind with -fPIC makes it fail? Should I file a bug report? Thanks Christophe. |
|
From: Julian S. <js...@ac...> - 2011-02-23 22:01:03
|
> such that the -fPIC which was present in my config.site CFLAGS is now > propagated to all valgrind components. > > So... is it expected that compiling valgrind with -fPIC makes it fail? > Should I file a bug report? Best not to mess with the compile flags. The valgrind executables are statically linked, by design, so -fPIC is meaningless anyway (you'll get something that won't work.) J |