| Summary: | vex amd64->IR: unhandled instruction bytes: 0x66 0x48 0xF 0x3A 0x16 0xA | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | kent.vandervelden |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | tdillig, tom |
| Priority: | NOR | ||
| Version: | 3.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 253451 | ||
|
Description
kent.vandervelden
2009-09-10 06:28:17 UTC
Please post contents of /proc/cpuinfo. Oh, it's a SSE4.1 insn, looks like. This is on a Core iSomething cpu? I get the same bug on a Xeon 5400 (core 2) CPU: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5430 @ 2.66GHz stepping : 6 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips : 5319.13 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: and some more cores. My error is: ==7349== Command: ./Debug/solver-ui ==7349== vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xA 0xC0 0x2 ==7349== valgrind: Unrecognised instruction at address 0x41cfe4. ==7349== Your program just tried to execute an instruction that Valgrind ==7349== did not recognise. There are two possible reasons for this. ==7349== 1. Your program has a bug and erroneously jumped to a non-code ==7349== location. If you are running Memcheck and you just saw a ==7349== warning about a bad jump, it's probably your program's fault. ==7349== 2. The instruction is legitimate but Valgrind doesn't handle it, ==7349== i.e. it's Valgrind's fault. If you think this is the case or ==7349== you are not sure, please let us know and we'll try to fix it. ==7349== Either way, Valgrind will now raise a SIGILL signal which will ==7349== probably kill your program. ==7349== ==7349== Process terminating with default action of signal 4 (SIGILL) ==7349== Illegal opcode at address 0x41CFE4 ==7349== at 0x41CFE4: std::_Hashtable<std::string, std::pair<std::string const, il::type*>, std::allocator<std::pair<std::string const, il::type*> >, std::_Select1st<std::pair<std::string const, il::type*> >, std::equal_to<std::string>, std::hash<std::string>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, false, false, true>::_Hashtable(unsigned long, std::hash<std::string> const&, std::__detail::_Mod_range_hashing const&, std::__detail::_Default_ranged_hash const&, std::equal_to<std::string> const&, std::_Select1st<std::pair<std::string const, il::type*> > const&, std::allocator<std::pair<std::string const, il::type*> > const&) (hashtable_policy.h:460) ==7349== by 0x43F2D0: global constructors keyed to VarMap.cpp (unordered_map:70) ==7349== by 0x498495: ??? (in /home/tdillig/research/solver-ui/Debug/solver-ui) ==7349== by 0x49EE52: ??? (in /home/tdillig/research/solver-ui/Debug/solver-ui) ==7349== by 0x5674F2F: ??? (in /usr/lib/libgtkmm-2.4.so.1.1.0) ==7349== by 0x498424: __libc_csu_init (in /home/tdillig/research/solver-ui/Debug/solver-ui) ==7349== by 0x9EACA4F: (below main) (libc-start.c:179) ==7349== ==7349== HEAP SUMMARY: ==7349== in use at exit: 8,745 bytes in 109 blocks ==7349== total heap usage: 110 allocs, 1 frees, 9,313 bytes allocated ==7349== ==7349== LEAK SUMMARY: ==7349== definitely lost: 120 bytes in 1 blocks ==7349== indirectly lost: 0 bytes in 0 blocks ==7349== possibly lost: 3,425 bytes in 103 blocks ==7349== still reachable: 5,200 bytes in 5 blocks ==7349== suppressed: 0 bytes in 0 blocks ==7349== Rerun with --leak-check=full to see details of leaked memory ==7349== ==7349== For counts of detected and suppressed errors, rerun with: -v ==7349== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) (In reply to comment #3) > I get the same bug on a Xeon 5400 (core 2) CPU: [snipped] > vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xA 0xC0 0x2 No, that's a different bug because the instruction bytes are different. Yours is ROUNDSS and was implemented in VEX r1986. The original error reported here is PEXTRQ which was implemented in VEX r1973. |