| Summary: | vex amd64->IR: unhandled instruction bytes: 0x62 0xD1 0xFE 0x8 0x6F 0x84 0x24 0x8 0x0 0x0 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Andras Szabo <andrei.hu> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | gabravier, tom |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Andras Szabo
2019-07-19 13:47:49 UTC
In 32 bit mode 0x62 would be BOUND which would win some sort of obscurity contest, but in 64 bit mode it doesn't appear to be valid and as far as I can see it hasn't been replaced by anything else, at least in the version of the Intel manual I am looking at... The latest (May 2019) edition seems to agree. Did you compile this yourself, and if you did what architecture did you target exactly? Here is the cpuinfo of the build host: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 80 On-line CPU(s) list: 0-79 Thread(s) per core: 2 Core(s) per socket: 20 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz Stepping: 4 CPU MHz: 3099.937 BogoMIPS: 4804.84 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 28160K NUMA node0 CPU(s): 0-19,40-59 NUMA node1 CPU(s): 20-39,60-79 As I look into the CMakeLists.txt file of rocksdb, i am seeing: -msse4.2 -mpclmul that stands out of the crowd. We used g++ 7.3 to build rocksdb. I am gonna collect build logs to provide more specific info. *** This bug has been marked as a duplicate of bug 393351 *** This bug has been reported 5 times in the past year, as bug numbers 393351, 409999, 414944, 411303 and 414053. I would like to fix it. I tried the steps-to-reproduce shown in bugs 393351 and 414053, but without success: I can't reproduce it either with the trunk or with 3.15.0. Without being able to reproduce it, I can't fix it. The first unhandled byte, 0x62, isn't the start of any known instruction (in 64-bit mode), so I suspect there has been some failure earlier on. Maybe Valgrind's instruction decoder lost track of where it was on the previous instruction. That's just a guess, though. What would be really helpful is if someone could reproduce the failure, and then use objdump -d to show the instructions around the failure point. I can give guidance on how to use objdump if that helps. If you want to try this, I suggest you first reproduce the failure while giving --demangle=no --sym-offsets=yes to Valgrind. That will make it much easier to relate the stack trace that Valgrind produces at the failure point, to the output of objdump -d. |