|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|
|Latest Commit:||Version Fixed In:|
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.