|
From: Mark T. <ma...@fl...> - 2007-06-04 01:58:11
|
When I run valgrind --tool=callgrind on anything at all, e.g. ls, I get output like the following: [18:41:48][mark:~/src/valgrind-3.2.3] $ valgrind -v --tool=callgrind ls ==17902== Callgrind, a call-graph generating cache profiler. ==17902== Copyright (C) 2002-2007, and GNU GPL'd, by Josef Weidendorfer et al. ==17902== Using LibVEX rev 1732, a library for dynamic binary translation. ==17902== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==17902== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==17902== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==17902== --17902-- Command line --17902-- ls --17902-- Startup, with flags: --17902-- -v --17902-- --tool=callgrind --17902-- Contents of /proc/version: --17902-- Linux version 2.6.21-gentooT (root@localhost) (gcc version 4.1.2(Gentoo 4.1.2)) #1 PREEMPT Fri Apr 27 13:27:49 PDT 2007 --17902-- Arch and hwcaps: X86, x86-sse1 --17902-- Page sizes: currently 4096, max supported 4096 --17902-- Valgrind library directory: /usr/lib/valgrind ==17902== For interactive control, run 'callgrind_control -h'. --17902-- Reading syms from /lib/ld-2.5.so (0x4000000) --17902-- Reading debug info from /usr/lib/debug/lib/ld-2.5.so.debug... valgrind: the 'impossible' happened: repeated section! ==17902== at 0x3801D29D: ??? sched status: running_tid=0 Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. I use Gentoo, but I also tried compiling the source myself with just CFLAGS=LDFLAGS="-ggdb". The only thing about my setup that I can imagine is possibly unusual is that I use FEATURES="splitdebug" in portage. It's roughly equivalent to this shell script I use when compiling things myself: #!/bin/bash for x in "$@" do y="/usr/lib/debug${x}.debug" mkdir -p "$(dirname $y)" objcopy --only-keep-debug "${x}" "${y}" objcopy --add-gnu-debuglink="${y}" "${x}" chmod a-x,o-w "${y}" strip "${x}" done That's what causes the line "--17902-- Reading debug info from /usr/lib/debug/lib/ld-2.5.so.debug...", if that's of any concern. I really don't want to have to deal with gprof, so any help would be appreciated. Of course, I will be willing to test patches and get backtraces for you. Mark |
|
From: Tom H. <to...@co...> - 2007-06-04 07:40:33
|
In message <c96...@ma...>
Mark Tiefenbruck <ma...@fl...> wrote:
> valgrind: the 'impossible' happened:
> repeated section!
[ snipped ]
> The only thing about my setup that I can imagine is possibly unusual is that
> I use FEATURES="splitdebug" in portage. It's roughly equivalent to this
> shell script I use when compiling things myself:
This seems to be a problem with a recent binutils, where it doesn't
properly remove all the sections from the base executable that have
been copied into the debug object, so some ELF sections wind up in
both and valgrind has no idea which one to use.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Mark T. <ma...@fl...> - 2007-06-04 18:25:26
|
> This seems to be a problem with a recent binutils, where it doesn't > properly remove all the sections from the base executable that have > been copied into the debug object, so some ELF sections wind up in > both and valgrind has no idea which one to use. Well, gdb seems to figure it out. I'm guessing the contents are identical. Maybe a check could be done on that. Anyway, for now, I'm guessing (just from what you said) that `strip' is the problem. I'll see if an older version of binutils helps. Mark |