SUMMARY Valgrind crashes with an unhandled instruction deep inside swrast_dri.so when running SuperTuxKart. STEPS TO REPRODUCE 1. In Windows Subsystem for Linux Bash, compile STK from GitHub 2. Run STK (commit 801aa127) with valgrind --leak-check=full --show-leak-kinds=definite --undef-value-errors=no bin/supertuxkart 3. Click No on connect to internet dialog 4. Click Story mode OBSERVED RESULT vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0x13 0x14 0x1A 0xC5 0xF9 0x6E 0xE9 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38 vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==19769== valgrind: Unrecognised instruction at address 0x422466a. ==19769== at 0x422466A: ??? ==19769== by 0x1213E352: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x1213E79C: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x1204186E: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x12037287: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x120376D4: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x123F3170: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x11E13BDE: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x11C79A6A: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x11C79B34: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0xDACE55: SP::SPMeshBuffer::draw(SP::DrawCallType, int) const (sp_mesh_buffer.hpp:127) ==19769== by 0xD8FE26: SP::draw(SP::RenderPass, SP::DrawCallType) (sp_base.cpp:1338) ==19769== Your program just tried to execute an instruction that Valgrind ==19769== did not recognise. There are two possible reasons for this. ==19769== 1. Your program has a bug and erroneously jumped to a non-code ==19769== location. If you are running Memcheck and you just saw a ==19769== warning about a bad jump, it's probably your program's fault. ==19769== 2. The instruction is legitimate but Valgrind doesn't handle it, ==19769== i.e. it's Valgrind's fault. If you think this is the case or ==19769== you are not sure, please let us know and we'll try to fix it. ==19769== Either way, Valgrind will now raise a SIGILL signal which will ==19769== probably kill your program. ==19769== ==19769== Process terminating with default action of signal 4 (SIGILL) ==19769== Illegal opcode at address 0x422466A ==19769== at 0x422466A: ??? ==19769== by 0x1213E352: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x1213E79C: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x1204186E: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x12037287: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x120376D4: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x123F3170: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x11E13BDE: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x11C79A6A: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0x11C79B34: ??? (in /usr/lib64/dri/swrast_dri.so) ==19769== by 0xDACE55: SP::SPMeshBuffer::draw(SP::DrawCallType, int) const (sp_mesh_buffer.hpp:127) ==19769== by 0xD8FE26: SP::draw(SP::RenderPass, SP::DrawCallType) (sp_base.cpp:1338) ==19769== ==19769== HEAP SUMMARY: ==19769== in use at exit: 241,808,846 bytes in 213,903 blocks ==19769== total heap usage: 2,177,891 allocs, 1,963,988 frees, 1,039,940,732 bytes allocated ==19769== ==19769== LEAK SUMMARY: ==19769== definitely lost: 0 bytes in 0 blocks ==19769== indirectly lost: 0 bytes in 0 blocks ==19769== possibly lost: 177,513,408 bytes in 69,823 blocks ==19769== still reachable: 64,295,438 bytes in 144,080 blocks ==19769== of which reachable via heuristic: ==19769== multipleinheritance: 704 bytes in 4 blocks ==19769== suppressed: 0 bytes in 0 blocks ==19769== Reachable blocks (those to which a pointer was found) are not shown. ==19769== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==19769== ==19769== For counts of detected and suppressed errors, rerun with: -v ==19769== ERROR SUMMARY: 26568 errors from 26568 contexts (suppressed: 0 from 0) Illegal instruction (core dumped) EXPECTED RESULT Valgrind shows whether there are any definite memory leaks SOFTWARE/OS VERSIONS Windows: 1903 (OS Build 18362.538) macOS: Linux/KDE Plasma: OpenSUSE 15.1 Windows Subsystem for Linux (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I tried to disassemble the indicated address (0x422466A) in GDB but GDB tells me that "No function contains specified address." This could be a duplicate of #356715 or #335785 – the first two bytes match
I forgot to mention I'm using VcXsrv 1.20.5.1 in "One large window" mode as the X server.
I believe this is vcvtph2ps (opcode 0x0f 0x38 0x13 with 0x66 prefix).
This is already fixed in 3.15.0 by the looks of it. *** This bug has been marked as a duplicate of bug 398870 ***
*** This bug has been marked as a duplicate of bug 356715 ***