Version: 3.7 SVN (using KDE 4.7.0) OS: Linux This illegal opcode appears when calling xmlXPathInit() from within an application. Both libxml2-2.7.8 and my application are compiled and run on Intel Core i3-2310M CPU. Even when building a program, which only contains this single call, the problem arises. I was not able to narrow down the exact call within xmlXPathInit, which causes the problem, nor do i know which instruction these opcode refers to. Valgrind SVN revision 12003. Reproducible: Always Steps to Reproduce: Compile and link a program against libxml2, which calls xmlXPathInit() Run this program with under valgrind. Actual Results: ==17277== Memcheck, a memory error detector ==17277== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17277== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info ==17277== Command: /home/jopen/test ==17277== vex amd64->IR: unhandled instruction bytes: 0xC5 0xF9 0x57 0xC0 0xC5 0xFB 0x10 0xD ==17277== valgrind: Unrecognised instruction at address 0x3f4e282890. ==17277== at 0x3F4E282890: xmlXPathInit (in /usr/lib64/libxml2.so.2.7.8) ==17277== by 0x400697: main (in /home/jopen/test) ==17277== Your program just tried to execute an instruction that Valgrind ==17277== did not recognise. There are two possible reasons for this. ==17277== 1. Your program has a bug and erroneously jumped to a non-code ==17277== location. If you are running Memcheck and you just saw a ==17277== warning about a bad jump, it's probably your program's fault. ==17277== 2. The instruction is legitimate but Valgrind doesn't handle it, ==17277== i.e. it's Valgrind's fault. If you think this is the case or ==17277== you are not sure, please let us know and we'll try to fix it. ==17277== Either way, Valgrind will now raise a SIGILL signal which will ==17277== probably kill your program. ==17277== ==17277== Process terminating with default action of signal 4 (SIGILL) ==17277== Illegal opcode at address 0x3F4E282890 ==17277== at 0x3F4E282890: xmlXPathInit (in /usr/lib64/libxml2.so.2.7.8) ==17277== by 0x400697: main (in /home/jopen/test) ==17277== ==17277== HEAP SUMMARY: ==17277== in use at exit: 0 bytes in 0 blocks ==17277== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==17277== ==17277== All heap blocks were freed -- no leaks are possible ==17277== ==17277== For counts of detected and suppressed errors, rerun with: -v ==17277== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) Expected Results: Valgrind should recognize the used instructions.
Can you post a disassembly of that function? Only if I'm reading the Intel manuals correctly then OxC5 is not valid in 64 bit mode...
So I've updated my manuals now and apparently "0xC5 0xF9" is a VEX prefix which is some new piece of insanity, because x86 instruction decoding just wasn't complicated enough... That leaves 0x57 as the real instruction, with an 0x0F prefix implied by the 2 byte VEX prefix. At the end of which we have 0x0F 0x57 otherwise known as xorps which is an instruction we do understand so it looks like the issue is that we don't know how to handle these new VEX prefixes.
I'm not sure, why x86 instructions are involved, because both my application, as well as libxml2 were compiled and run on a 64-bit OS. Shouldn't the processor run in 64-bit native mode or compatibility mode? Anyway, if you need further information, feel free to give me instructions, what to do. Regarding the disassembly, is this still necessary? If so, can you please tell me, what i have to do and which tools to use?
Sorry, I was using x86 as shorthand for the whole family including both 32 and 64 bit instructions. I think we know what the problem is, but I'm guessing it's not going to be solved very quickly as adding logic to decode and handle VEX prefixes looks like it will be rather non-trivial. For the time being you probably need to tone down your optimisation settings to something valgrind can cope with. Compiling for the full range of instructions on a recent processor is always likely to lead to problems I'm afraid.
(In reply to comment #2) > So I've updated my manuals now and apparently "0xC5 0xF9" is a VEX prefix which > is some new piece of insanity, because x86 instruction decoding just wasn't > complicated enough... Yeah, it basically means it's an AVX insn. Doing AVX is going to be a whole trip since it largely duplicates SSE2 but makes it 256 bits wide instead. It will get fixed, but not in the next few weeks.
Thanks for the fast replies. Compiling libxml2 without optimizations indeed "fixes" the problem, at least for now.
(In reply to comment #2) > So I've updated my manuals now and apparently "0xC5 0xF9" is a VEX prefix which > is some new piece of insanity, because x86 instruction decoding just wasn't > complicated enough... Yeah, it elevates it into the surreal. It's kind of like having your instruction set encoding designed by Salvador Dali. Anyway, closing this as a dup of the canonical AVX tracking bug (bug 273475). *** This bug has been marked as a duplicate of bug 273475 ***