Bug 388407 - vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x29
Summary: vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x29
Status: RESOLVED DUPLICATE of bug 384230
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.13.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-31 18:31 UTC by sdelang
Modified: 2018-01-01 09:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sdelang 2017-12-31 18:31:43 UTC
$ uname -a
Linux sdelang-arch 4.14.1-1-ck #1 SMP PREEMPT Thu Nov 23 19:51:37 CET 2017 x86_64 GNU/Linux

$ valgrind -v ./KAG
==26570== Memcheck, a memory error detector
==26570== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26570== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26570== Command: ./KAG
...
vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x29
==26570== valgrind: Unrecognised instruction at address 0x4fae45f.
==26570==    at 0x4FAE45F: ??? (in /usr/lib32/libGLdispatch.so.0.0.0)
==26570==    by 0x400F8EA: call_init.part.0 (in /usr/lib32/ld-2.26.so)
==26570==    by 0x400F9F6: _dl_init (in /usr/lib32/ld-2.26.so)
==26570==    by 0x4000C9E: ??? (in /usr/lib32/ld-2.26.so)
==26570== Your program just tried to execute an instruction that Valgrind
==26570== did not recognise.  There are two possible reasons for this.
==26570== 1. Your program has a bug and erroneously jumped to a non-code
==26570==    location.  If you are running Memcheck and you just saw a
==26570==    warning about a bad jump, it's probably your program's fault.
==26570== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26570==    i.e. it's Valgrind's fault.  If you think this is the case or
==26570==    you are not sure, please let us know and we'll try to fix it.
==26570== Either way, Valgrind will now raise a SIGILL signal which will
==26570== probably kill your program.
==26570== 
==26570== Process terminating with default action of signal 4 (SIGILL): dumping core
==26570==  Illegal opcode at address 0x4FAE45F
==26570==    at 0x4FAE45F: ??? (in /usr/lib32/libGLdispatch.so.0.0.0)
==26570==    by 0x400F8EA: call_init.part.0 (in /usr/lib32/ld-2.26.so)
==26570==    by 0x400F9F6: _dl_init (in /usr/lib32/ld-2.26.so)
==26570==    by 0x4000C9E: ??? (in /usr/lib32/ld-2.26.so)
--26570-- REDIR: 0x4dfee80 (libc.so.6:free) redirected to 0x48306b0 (free)
==26570== 
==26570== HEAP SUMMARY:
==26570==     in use at exit: 10,356 bytes in 6 blocks
==26570==   total heap usage: 6 allocs, 0 frees, 10,356 bytes allocated
==26570== 
==26570== Searching for pointers to 6 not-freed blocks
==26570== Checked 473,192 bytes
==26570== 
==26570== LEAK SUMMARY:
==26570==    definitely lost: 0 bytes in 0 blocks
==26570==    indirectly lost: 0 bytes in 0 blocks
==26570==      possibly lost: 0 bytes in 0 blocks
==26570==    still reachable: 10,356 bytes in 6 blocks
==26570==         suppressed: 0 bytes in 0 blocks
==26570== Rerun with --leak-check=full to see details of leaked memory
==26570== 
==26570== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==26570== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[1]    26570 illegal hardware instruction (core dumped)  valgrind -v ./KAG

Using lib32-mesa 17.3.1-2 from arch repos.
Using nouveau, lib32-libglvnd 1.0.0-1, linux-ck built as of Linux 4.14.1 if it helps with anything.

This is the software reproducing the issue: https://kag2d.com/en/download.
I can try to make a minimal program reproducing the issue if you desire, but I would be unsurprised if it affected all x86 OpenGL programs with that setup.

Thanks in advance, valgrind is wonderful software :)
Comment 1 Tom Hughes 2018-01-01 09:27:39 UTC
*** This bug has been marked as a duplicate of bug 384230 ***