https://bugs.kde.org/show_bug.cgi?id=406669
Bug ID: 406669
Summary: vex amd64->IR: unhandled instruction bytes: 0xC5 0xD4
0xC2 0xED 0xF 0xC5 0xFC 0x29 0xAC 0x24
Product: valgrind
Version: 3.14.0
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: pa...@luccalug.it
Target Milestone: ---
I'm playing around with QtWebKit and WebGL. The program runs smoothly without
valgrind, while valgrind makes it fail:
vex amd64->IR: unhandled instruction bytes: 0xC5 0xD4 0xC2 0xED 0xF 0xC5 0xFC
0x29 0xAC 0x24
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=1 VEX.L=1 VEX.nVVVV=0x5 ESC=0F
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==7397== valgrind: Unrecognised instruction at address 0x540b16fe.
==7397== at 0x540B16FE: ???
==7397== by 0x5CA00A7B: ??? (in /usr/lib/dri/swrast_dri.so)
==7397== by 0x5C9FEEA4: ??? (in /usr/lib/dri/swrast_dri.so)
==7397== by 0x5C9FF47C: ??? (in /usr/lib/dri/swrast_dri.so)
==7397== by 0x5C9FF377: ??? (in /usr/lib/dri/swrast_dri.so)
==7397== by 0x9ED3A9C: start_thread (in /usr/lib/libpthread-2.28.so)
==7397== by 0x93CEAF2: clone (in /usr/lib/libc-2.28.so)
==7397== Your program just tried to execute an instruction that Valgrind
==7397== did not recognise. There are two possible reasons for this.
==7397== 1. Your program has a bug and erroneously jumped to a non-code
==7397== location. If you are running Memcheck and you just saw a
==7397== warning about a bad jump, it's probably your program's fault.
==7397== 2. The instruction is legitimate but Valgrind doesn't handle it,
==7397== i.e. it's Valgrind's fault. If you think this is the case or
==7397== you are not sure, please let us know and we'll try to fix it.
==7397== Either way, Valgrind will now raise a SIGILL signal which will
==7397== probably kill your program.
I believe that the instruction is legitimate because:
- It looks like the opcode is deep in a mesa library, which I believe is likely
to use many CPU extensions.
- My program runs smoothly without valgrind, and my system and programs are
stable. Besides valgrind isn't noticing any memory violations.
- Few days ago valgrind was failing on the very same opcode. Then I kept
changing the code and it stopped failing until now. The code is quite different
from days ago and I think it's unlikely that I restarted jumping at memory
addresses with the identical 10 bytes.
My system is:
- Kernel: 5.0.7-arch1-1-ARCH,
- CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz
- CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm cpuid_fault epb pti tpr_shadow vnmi flexpriority ept vpid fsgsbase smep
erms xsaveopt dtherm ida arat pln pts
- GPU: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
(prog-if 00 [VGA controller]), integrated in the CPU
- Graphics module: i915, from xf86-video-intel 1:2.99.917+863+g6afed33b-1
- Valgrind: 3.14.0-1
--
You are receiving this mail because:
You are watching all bug changes.
