Bug 328089

Summary: vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10
Product: [Developer tools] valgrind Reporter: maurice van swaaij <maurice>
Component: vexAssignee: Julian Seward <jseward>
Status: RESOLVED DUPLICATE    
Severity: normal CC: tom
Priority: NOR    
Version: 3.8.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description maurice van swaaij 2013-11-25 23:00:08 UTC
::      0x00bf1015:               0xf0  lock xaddb  %dl,(%rax)
          0x00bf1016:               0x0f
          0x00bf1017:               0xc0
          0x00bf1018:               0x10

Inspection of the assembly code leads me to think it is the above instruction that isn't handled.

Reproducible: Sometimes

Steps to Reproduce:
The instruction comes from using intel's thread building blocks (tbb) toolkit and the class::method below

tbb::queuing_mutex::scoped_lock::scoped_lock( queuing_mutex& m )

Actual Results:  
vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x80 0xFA 0x1 0xF
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==32386== valgrind: Unrecognised instruction at address 0xbf1015.


Expected Results:  
Keep running.


Although we have been using tbb for a while, this is the first time we hit this problem, probably because we have introduced a lock in a high-contention area.

To run with tbb, we did have to suppress two tbb related issues, that don't seem to be the cause of the problem:

 {
   tbb::isLargeObject 
   Memcheck:Cond
   fun:_ZN3rml8internal13isLargeObjectEPv
   fun:_ZN3rml8internalL16internalPoolFreeEPNS0_10MemoryPoolEPv
}

{
   tbb::getBackRef
   Memcheck:Cond
   fun:_ZN3rml8internal10getBackRefENS0_10BackRefIdxE
   fun:_ZN3rml8internal13isLargeObjectEPv
   fun:_ZN3rml8internalL16internalPoolFreeEPNS0_10MemoryPoolEPv
}
Comment 1 maurice van swaaij 2013-12-02 17:17:16 UTC
Running with valgrind 3.9.0 did not repeat the problem. 
Is there an easy way to confirm that the instruction (0xF0 0xF 0xC0 0x10) is handled by looking in the source?

Thanks.
Comment 2 Julian Seward 2014-05-12 14:55:14 UTC
Yes, it was fixed in 307106.

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