Version: svn from Fri Jul 13 00:32:48 CEST 2007 (using KDE Devel) Installed from: Compiled sources Compiler: gcc 4.2 amd64 OS: Linux --9396-- DWARF2 CFI reader: unhandled DW_OP_ opcode 0x6 valgrind: m_debuginfo/readdwarf.c:2118 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. ==9396== at 0x38018614: ??? sched status: running_tid=0 I tried compiling my app with -g, without -g and with -s. I tried linking dynamically or statically. Interestingly enough, it does work when I compile and link my app against dietlibc, but then I don't get the malloc checking.
I can confirm this behavior to 100%. Exactly the same assertion fails on my amd64-machine with gcc 4.2.1 and glibc 2.6.1. A simple, statically linked test-program compiled using dietlibc worked here, but without malloc checking, too.
> --9396-- DWARF2 CFI reader: unhandled DW_OP_ opcode 0x6 Uh, potentially serious bug. Do you have a simple test case?
Sure, I'll attach a hello world binary. This is actually quite interesting, because when I copy the binary to my Gentoo box and run the valgrind-3.2.3 on that box against the binary, it works. When I run the valgrind-3.3.0-SVN on my notebook (where I created it) against the binary, it fails. So apparently Gentoo already has a fix for the problem applied to their valgrind version...? The binary is at http://dl.fefe.de/hello
Created attachment 21482 [details] hello world exhibiting the problem
Yup, the very same thing on openSUSE 10.3 Beta 2 (gcc 4.2.1, glibc 2.6.1). I can reproduce it with any binary I try. # valgrind ls <..skip the header ..> --24337-- DWARF2 CFI reader: unhandled DW_OP_ opcode 0x6 valgrind: m_debuginfo/readdwarf.c:2118 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. ==24337== at 0x38018DA8: ??? sched status: running_tid=0 I'm ready to provide you any additional info you need, just let me know.
> I'm ready to provide you any additional info you need, just let me know. Ok. Let's do this in stages. First, rerun with "-v" and send the complete output.
Here is what I get with fresh SVN checkout: # valgrind -v ls ==27910== Memcheck, a memory error detector. ==27910== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==27910== Using LibVEX rev 1786, a library for dynamic binary translation. ==27910== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==27910== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==27910== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==27910== --27910-- Command line --27910-- ls --27910-- Startup, with flags: --27910-- -v --27910-- Contents of /proc/version: --27910-- Linux version 2.6.22.3-7-default (geeko@buildhost) (gcc version 4.2.1 (SUSE Linux)) #1 SMP 2007/08/20 16:50:09 UTC --27910-- Arch and hwcaps: AMD64, amd64-sse2 --27910-- Page sizes: currently 4096, max supported 4096 --27910-- Valgrind library directory: /usr/lib64/valgrind --27910-- Reading syms from /bin/ls (0x400000) --27910-- object doesn't have a symbol table --27910-- Reading syms from /lib64/ld-2.6.1.so (0x4000000) --27910-- object doesn't have a symbol table --27910-- DWARF2 CFI reader: unhandled DW_OP_ opcode 0x6 valgrind: m_debuginfo/readdwarf.c:2118 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. ==27910== at 0x38018DA8: ??? 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 can confirm the above behavior with valgrind trunk r1786 and gcc 4.1.3 on an amd64 ubuntu gutsy C2D box. Steps to reproduce: 1. svn co -r 1786 valgrind 2. build, install 3. ./hello --21862-- DWARF2 CFI reader: unhandled DW_OP_ opcode 0x6
Re Comment #7 From Antony Dovgal. Can you send me the /lib64/ld-2.6.1.so from the machine where you got the crash. The failure occurs whilst reading the stack unwind info from that shared object, so if I had it I might be able to reproduce it.
Sure, here is it: http://daylessday.org/files/ld-2.6.1.so
Fixed (svn r6793). I'm not 100% confident about the fix so it would be helpful if you could check out the trunk and try it.
Works great now, many thanks.
Fixed.