Bug 415382 - vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0x13 0x14 0x1A 0xC5 0xF9 0x6E 0xE9
Summary: vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0x13 0x14 0x1A 0xC...
Status: RESOLVED DUPLICATE of bug 356715
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.14.0
Platform: openSUSE Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-20 06:18 UTC by Nathan Mills
Modified: 2019-12-21 00: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 Nathan Mills 2019-12-20 06:18:20 UTC
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
Comment 1 Nathan Mills 2019-12-20 22:16:46 UTC
I forgot to mention I'm using VcXsrv 1.20.5.1 in "One large window" mode as the X server.
Comment 2 Tom Hughes 2019-12-21 00:21:15 UTC
I believe this is vcvtph2ps (opcode 0x0f 0x38 0x13 with 0x66 prefix).
Comment 3 Tom Hughes 2019-12-21 00:24:52 UTC
This is already fixed in 3.15.0 by the looks of it.

*** This bug has been marked as a duplicate of bug 398870 ***
Comment 4 Tom Hughes 2019-12-21 00:27:03 UTC

*** This bug has been marked as a duplicate of bug 356715 ***