Bug 191062 - unhandled instruction bytes: 0xF 0xB 0x78 0x65
Summary: unhandled instruction bytes: 0xF 0xB 0x78 0x65
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.4.1
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-29 19:07 UTC by Robert Ellison
Modified: 2019-08-04 09:03 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Ellison 2009-04-29 19:07:32 UTC
Version:           3.4.1 (using Devel)
Compiler:          gcc 4.2.4 
OS:                Linux
Installed from:    Compiled sources

I'm using valgrind to track down a memory leak in the VMware vmware-vmx executable.  (I had to do some handstands to make it run at all, as by default the vmware-vmx executable is setuid root, but I got through that).

I'm running VMware Workstation on Ubuntu 8.04, trying to run a Windows XP virtual machine.  When vmware-vmx starts up under valgrind, I get:

      vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x78 0x65
      ==2150== valgrind: Unrecognised instruction at address 0x817B538.
      ==2150== Your program just tried to execute an instruction that Valgrind
      ==2150== did not recognise.  There are two possible reasons for this.
      ==2150== 1. Your program has a bug and erroneously jumped to a non-code
      ==2150==    location.  If you are running Memcheck and you just saw a
      ==2150==    warning about a bad jump, it's probably your program's fault.
      ==2150== 2. The instruction is legitimate but Valgrind doesn't handle it,
      ==2150==    i.e. it's Valgrind's fault.  If you think this is the case or
      ==2150==    you are not sure, please let us know and we'll try to fix it.
      ==2150== Either way, Valgrind will now raise a SIGILL signal which will
      ==2150== probably kill your program.

Indeed, it does kill the program.
Comment 1 Tom Hughes 2009-04-29 19:25:57 UTC
If I'm reading my manuals right then 0x0F 0x0B is the "UD2" instruction, whose only purpose is to generate an invalid opcode exception... As that's exactly what valgrind has apparently done it's a bit surprising it has killed the program. Maybe we didn't quite fill in the siginfo in the way it was expecting.
Comment 2 Nicholas Nethercote 2009-06-25 07:16:02 UTC
It would probably be better if Valgrind handled UD2 distincly, not in a "I don't know what this instruction is" way.  Ie. if it just raised the exception without the message.
Comment 3 Nicholas Nethercote 2009-06-29 07:10:44 UTC
A user who hit this had a suggested workaround, something like:

> #ifndef NDEBUG
> #include <valgrind/valgrind.h>
> #else
> #define RUNNING_ON_VALGRIND 0
> #endif
>
> main()
> {
>   .....
>   if (RUNNING_ON_VALGRIND)
>     signal(SIGILL, dummy_valgrind_handler)
>   else
>     signal(SIGILL, normal_sigill_handler)

which is hacky but better than nothing.
Comment 4 Tom Hughes 2019-08-04 09:03:03 UTC
*** Bug 410562 has been marked as a duplicate of this bug. ***