https://bugs.kde.org/show_bug.cgi?id=388407
Bug ID: 388407
Summary: vex x86->IR: unhandled instruction bytes: 0x67 0xE8
0xAB 0x29
Product: valgrind
Version: 3.13.0
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: sdel...@sdelang.fr
Target Milestone: ---
$ 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 :)
--
You are receiving this mail because:
You are watching all bug changes.
