| Summary: | vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | maurice van swaaij <maurice> |
| Component: | vex | Assignee: | 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: | ||
| Sentry Crash Report: | |||
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. Yes, it was fixed in 307106. *** This bug has been marked as a duplicate of bug 307106 *** |
:: 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 }