Bug 189396 – dev-util/valgrind-3.2.3 illegal instruction with glibc-2.6.1 on x86_64

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Tiziano Müller (RETIRED) 2007-08-18 19:29:02 UTC]

valgrind /bin/true gives me the following:

==26300== Memcheck, a memory error detector.
==26300== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==26300== Using LibVEX rev 1732, a library for dynamic binary translation.
==26300== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==26300== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==26300== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==26300== For more details, rerun with: -v
==26300==
vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
==26300== valgrind: Unrecognised instruction at address 0x4014231.
==26300== Your program just tried to execute an instruction that Valgrind
==26300== did not recognise.  There are two possible reasons for this.
==26300== 1. Your program has a bug and erroneously jumped to a non-code
==26300==    location.  If you are running Memcheck and you just saw a
==26300==    warning about a bad jump, it's probably your program's fault.
==26300== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26300==    i.e. it's Valgrind's fault.  If you think this is the case or
==26300==    you are not sure, please let us know and we'll try to fix it.
==26300== Either way, Valgrind will now raise a SIGILL signal which will
==26300== probably kill your program.
==26300==
==26300== Process terminating with default action of signal 4 (SIGILL)
==26300==  Illegal opcode at address 0x4014231
==26300==    at 0x4014231: memcpy (in /lib64/ld-2.6.1.so)
==26300==    by 0x4004280: dl_main (in /lib64/ld-2.6.1.so)
==26300==    by 0x4012729: _dl_sysdep_start (in /lib64/ld-2.6.1.so)
==26300==    by 0x4001F42: _dl_start (in /lib64/ld-2.6.1.so)
==26300==    by 0x4000B17: (within /lib64/ld-2.6.1.so)
==26300==
==26300== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==26300== malloc/free: in use at exit: 0 bytes in 0 blocks.
==26300== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==26300== For counts of detected errors, rerun with: -v
==26300== All heap blocks were freed -- no leaks are possible.
Illegal instruction

[Comment 1 Maurice van der Pot (RETIRED) 2007-08-19 01:50:54 UTC]

I will be away next week, but if you really need a patch keep an eye on the following bug report in KDE's bugzilla:

http://bugs.kde.org/show_bug.cgi?id=148447

[Comment 2 Maurice van der Pot (RETIRED) 2007-08-26 09:34:14 UTC]

I took upstream's fix and added it as a patch for valgrind-3.2.3.
Please resync & remerge to get it.

[Comment 3 Tiziano Müller (RETIRED) 2007-08-26 14:53:29 UTC]

Doesn't this usually request a version bump since it's not a build problem?

[Comment 4 Maurice van der Pot (RETIRED) 2007-08-26 17:59:38 UTC]

I thought about it but I didn't want to force everyone else who will never experience this issue to upgrade.

[Comment 5 Jakub Moc (RETIRED) 2007-10-06 10:56:38 UTC]

*** Bug 194875 has been marked as a duplicate of this bug. ***

[Comment 6 REMOVED ACCOUNT 2007-10-20 16:37:27 UTC]

(In reply to comment #4)
> I thought about it but I didn't want to force everyone else who will never
> experience this issue to upgrade.

Please reconsider -- I just wasted half an hour 1) searching for the bug and 2) preparing ebuild patch after I didn't find any open valgrind bug in Gentoo's Bugzilla, because it didn't occur to me that such a serious bug could be already fixed silently :-/

[Comment 7 Maurice van der Pot (RETIRED) 2007-10-20 18:16:35 UTC]

Ok, I've checked in 3.2.3-r1, which is (apart from header and keywords) an exact copy of 3.2.3. amd64, could you please stable this ebuild?

[Comment 8 Chris Gianelloni (RETIRED) 2007-11-06 00:57:31 UTC]

amd64 stable... feel free to REOPEN if you want the other arches to do the same, so you'll have fewer ebuilds to maintain...