Originally https://bugzilla.redhat.com/show_bug.cgi?id=755242#c7 valgrind-3.8.1-3.fc17 fails. [mrsam@octopus base]$ valgrind --tool=memcheck ./testhttpclientauth ==28524== Memcheck, a memory error detector ==28524== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==28524== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==28524== Command: ./testhttpclientauth ==28524== vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x84 0xD2 0xF 0x95 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==28524== valgrind: Unrecognised instruction at address 0x56c947.
Weird, that is lock xaddb %dl,(%rax), that ought to be handled...
confirmed, valgrind 3.7.0 works fine, but with 3.8.x and also with upstream valgrind SVN: $ /usr/local/install/valgrind/bin/valgrind -q --vgdb-error=0 ./test ==4405== (action at startup) vgdb me ... ==4405== ==4405== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==4405== /path/to/gdb ./test ==4405== and then give GDB the following command ==4405== target remote | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405 ==4405== --pid is optional if only one valgrind process is running ==4405== (gdb) target remote | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405 Remote debugging using | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405 relaying data between gdb and process 4405 Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.15.so.debug...done. done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 [Switching to Thread 4405] 0x0000000004001530 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) c Continuing. Program received signal SIGILL, Illegal instruction. 0x00000000004004a7 in main () (gdb) disassemble Dump of assembler code for function main: 0x000000000040049c <+0>: push %rbp 0x000000000040049d <+1>: mov %rsp,%rbp 0x00000000004004a0 <+4>: mov %edi,-0x4(%rbp) 0x00000000004004a3 <+7>: mov %rsi,-0x10(%rbp) => 0x00000000004004a7 <+11>: lock xadd %dl,(%rax) 0x00000000004004ab <+15>: mov $0x0,%eax 0x00000000004004b0 <+20>: pop %rbp 0x00000000004004b1 <+21>: retq End of assembler dump. (gdb)
Created attachment 628051 [details] valgrind-xaddb.patch I'm probably missing something obvious, but to me it looks like xaddb handling in valgrind 3.7.x and earlier was misplaced and with AVX merge it got commented out.
Confirmed with upstream. "it got disabled during the massive reorganisation of that insn decoder last year, and never got re-enabled" https://bugs.kde.org/show_bug.cgi?id=307106
valgrind-3.8.1-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/valgrind-3.8.1-4.fc17
valgrind-3.8.1-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-16133/valgrind-3.8.1-4.fc18
Package valgrind-3.8.1-4.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing valgrind-3.8.1-4.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16272/valgrind-3.8.1-4.fc17 then log in and leave karma (feedback).
valgrind-3.8.1-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.