Summary: | Invalid Instruction in optimized glibc __mpn_construct_double | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Palmer Dabbelt <palmem> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | tom |
Priority: | NOR | ||
Version: | 3.7.0 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Calls atof |
*** This bug has been marked as a duplicate of bug 273475 *** |
Created attachment 68202 [details] Calls atof I'm running Gentoo on a Core i5 and I've built glibc with "-O2 --march=native". It seems that some optimization generates an instruction that valgrind doesn't understand. I've attached a fairly simple test program (test.c) that can be built with "gcc test.c -o test". The test just consists of running atof on a constant string. I'm running glibc 2.13, valgrind 3.7.0 and GCC 4.5.3. My CPU is reported as a "Intel(R) Core(TM) i5-2500K CPU" by /proc/cpuinfo. Here is the output I get from valgrind running on my optimized glibc (built with "-O2 --march=native"): $ valgrind ./test ==29368== Memcheck, a memory error detector ==29368== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==29368== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==29368== Command: ./test ==29368== vex amd64->IR: unhandled instruction bytes: 0xC5 0xFB 0x10 0x44 0x24 0xF8 0xC3 0x90 ==29368== valgrind: Unrecognised instruction at address 0x4e74f13. ==29368== at 0x4E74F13: __mpn_construct_double (in /lib64/libc-2.13.so) ==29368== by 0x4E6D6B3: ____strtod_l_internal (in /lib64/libc-2.13.so) ==29368== by 0x40059C: main (in /home/palmer/.local/src/valgrind/test) ==29368== Your program just tried to execute an instruction that Valgrind ==29368== did not recognise. There are two possible reasons for this. ==29368== 1. Your program has a bug and erroneously jumped to a non-code ==29368== location. If you are running Memcheck and you just saw a ==29368== warning about a bad jump, it's probably your program's fault. ==29368== 2. The instruction is legitimate but Valgrind doesn't handle it, ==29368== i.e. it's Valgrind's fault. If you think this is the case or ==29368== you are not sure, please let us know and we'll try to fix it. ==29368== Either way, Valgrind will now raise a SIGILL signal which will ==29368== probably kill your program. ==29368== ==29368== Process terminating with default action of signal 4 (SIGILL) ==29368== Illegal opcode at address 0x4E74F13 ==29368== at 0x4E74F13: __mpn_construct_double (in /lib64/libc-2.13.so) ==29368== by 0x4E6D6B3: ____strtod_l_internal (in /lib64/libc-2.13.so) ==29368== by 0x40059C: main (in /home/palmer/.local/src/valgrind/test) ==29368== ==29368== HEAP SUMMARY: ==29368== in use at exit: 0 bytes in 0 blocks ==29368== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==29368== ==29368== All heap blocks were freed -- no leaks are possible ==29368== ==29368== For counts of detected and suppressed errors, rerun with: -v ==29368== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) Illegal instruction And here is the output on a less-optimized glibc (just built with "-O2"): $ valgrind ./test ==3851== Memcheck, a memory error detector ==3851== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==3851== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==3851== Command: ./test ==3851== d: -2.000000 ==3851== ==3851== HEAP SUMMARY: ==3851== in use at exit: 0 bytes in 0 blocks ==3851== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==3851== ==3851== All heap blocks were freed -- no leaks are possible ==3851== ==3851== For counts of detected and suppressed errors, rerun with: -v ==3851== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)