Bug 112432

Summary:	vex amd64->IR: unhandled instruction bytes: bound (0x4F 0x62 0x6A 0x65)
Product:	[Developer tools] valgrind	Reporter:	Hamish Rodda <rodda>
Component:	vex	Assignee:	Julian Seward <jseward>
Status:	RESOLVED NOT A BUG
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Hamish Rodda 2005-09-11 16:47:47 UTC

Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc-4.0.2 
OS:                Linux

Running memcheck on kdevelop 3 branch, after a few bugs were fixed in kdevelop, leads to the following behaviour:

hamish@sleek:/opt/kde/build/kdevelop/parts/diff$ valgrind --num-callers=16 --error-limit=no kdevelop
==29624== Memcheck, a memory error detector.
==29624== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==29624== Using LibVEX rev 1385, a library for dynamic binary translation.
==29624== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==29624== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework.
==29624== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==29624== For more details, rerun with: -v
==29624==

(lots of errors and application output snipped)

vex amd64->IR: unhandled instruction bytes: 0x4F 0x62 0x6A 0x65

KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kdevelop path = <unknown> pid = 29624

==29624==
==29624== ERROR SUMMARY: 675 errors from 69 contexts (suppressed: 315 from 12)
==29624== malloc/free: in use at exit: 7365949 bytes in 163531 blocks.
==29624== malloc/free: 1196147 allocs, 1032616 frees, 59371032 bytes allocated.
==29624== For counts of detected errors, rerun with: -v
==29624== searching for pointers to 163531 not-freed blocks.
==29624== checked 10786880 bytes.
==29624==
==29624== LEAK SUMMARY:
==29624==    definitely lost: 2582 bytes in 60 blocks.
==29624==      possibly lost: 152 bytes in 1 blocks.
==29624==    still reachable: 7363215 bytes in 163470 blocks.
==29624==         suppressed: 0 bytes in 0 blocks.
==29624== Use --leak-check=full to see details of leaked memory.

Let me know what I can do to provide more information if you need it.

Comment 1 Tom Hughes 2005-09-13 10:33:19 UTC

This is a BOUND instruction. What is odd is that it has a REX prefix and you're running 64 bit code but the AMD manual says BOUND is invalid in 64 bit mode and that it will always generate an invalid opcode fault in 64 bit mode.

That strongly suggests that your application has gone wrong and has jumped through a bad pointer and is no longer executing valid code.

Unfortunately KDE seems to have caught the SIGILL so we're not getting a backtrace to tell us what address the invalid instruction was at.

Comment 2 Thiago Macieira 2005-09-13 13:14:56 UTC

Hint: start your application with --nocrashhandler or set the KDE_DEBUG environment variable to anything.

Comment 3 Julian Seward 2005-10-05 19:10:14 UTC

Hamish, is this bug still alive?  Considering Tom's comments I'd
like to close it as invalid unless it is still biting you.

Comment 4 Tom Hughes 2005-10-06 01:17:29 UTC

Note that there is still an open bug (bug 105227) complaining about BOUND in 32 bit code.

Comment 5 Julian Seward 2005-10-06 05:01:12 UTC

That's doable; however I'm not sure what's supposed to happen if the
bounds test fails.  The Intel docs say an INT 5 is generated.  What 
does that look like after the kernel delivers it to userspace?  I'd
guess we have to synth a signal of some flavour, but what?

Comment 6 Hamish Rodda 2005-10-06 10:25:47 UTC

By turning off the crash handler I was able to identify the problem with the code which was causing this problem.  I can't recall if I managed to fix the code (don't think so, it was a complex problem iirc).  So, from my point of view Valgrind is not doing anything more incorrect than giving a bit of a cryptic error message. You can close this, thanks.

Comment 7 Tom Hughes 2005-10-06 10:37:16 UTC

I'll close this then.