On Fri, Feb 7, 2014 at 3:28 PM, Adam.Jirasek <adam.jira...@gmail.com> wrote: > Hello > > I have a C program which I routinely test with valgrind. > The platform is Intel i3 dual core, gcc-4.7.3. and for all my tests > valgrind did not give any warning when I started my program > > > Now I updated to a new computer > Intel i7 4th generation, gcc-4.7.3 and when I start valgrind with my > code I get: > > valgrind --tool=memcheck --trace-children=yes > --vex-iropt-register-updates=allregs-at-mem-access --leak-check=full > --leak-resolution=high --show-reachable=yes --track-origins=yes > ../../Source/Server_Main.out --port 31000 --input_file > Definition_File_PDT_Modes --show > ==28771== Memcheck, a memory error detector > ==28771== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==28771== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==28771== Command: ../../Source/Server_Main.out --port 31000 > --input_file Definition_File_PDT_Modes --show > ==28771== > vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 > 0x89 0x45 0x80 > vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1 > vex amd64->IR: VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38 > vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 > ==28771== valgrind: Unrecognised instruction at address 0x400da4b. > ==28771== at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so) > ==28771== by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so) > ==28771== by 0x4003128: dl_main (in /lib64/ld-2.17.so) > ==28771== by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so) > ==28771== by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so) > ==28771== by 0x4001647: ??? (in /lib64/ld-2.17.so) > ==28771== by 0x5: ??? > ==28771== by 0x7FF000056: ??? > ==28771== by 0x7FF000073: ??? > ==28771== by 0x7FF00007A: ??? > ==28771== by 0x7FF000080: ??? > ==28771== by 0x7FF00008D: ??? > ==28771== Your program just tried to execute an instruction that Valgrind > ==28771== did not recognise. There are two possible reasons for this. > ==28771== 1. Your program has a bug and erroneously jumped to a non-code > ==28771== location. If you are running Memcheck and you just saw a > ==28771== warning about a bad jump, it's probably your program's fault. > ==28771== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==28771== i.e. it's Valgrind's fault. If you think this is the case or > ==28771== you are not sure, please let us know and we'll try to fix it. > ==28771== Either way, Valgrind will now raise a SIGILL signal which will > ==28771== probably kill your program. > ==28771== > ==28771== Process terminating with default action of signal 4 (SIGILL) > ==28771== Illegal opcode at address 0x400DA4B > ==28771== at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so) > ==28771== by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so) > ==28771== by 0x4003128: dl_main (in /lib64/ld-2.17.so) > ==28771== by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so) > ==28771== by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so) > ==28771== by 0x4001647: ??? (in /lib64/ld-2.17.so) > ==28771== by 0x5: ??? > ==28771== by 0x7FF000056: ??? > ==28771== by 0x7FF000073: ??? > ==28771== by 0x7FF00007A: ??? > ==28771== by 0x7FF000080: ??? > ==28771== by 0x7FF00008D: ??? > ==28771== > ==28771== HEAP SUMMARY: > ==28771== in use at exit: 0 bytes in 0 blocks > ==28771== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==28771== > ==28771== All heap blocks were freed -- no leaks are possible > ==28771== > ==28771== For counts of detected and suppressed errors, rerun with: -v > ==28771== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > Illegal instruction > > > > Any advice what my be causing such a warning? >
Yes, you've emitted an instruction that valgrind does not handle. Searching for the same instruction string on google, I found that there was already a bug filed for this. You can try limiting your instruction set when you compile. I do not know exactly what instruction this is, but if you can determine that, you can try to get the compiler not to emit it. I notice that you're also running valgrind that only has copyright up to 2012. Maybe try the latest version? Brian ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
