In this run, we're using valgrind 3.3.0 on a RHEL3 machine fogo[/home/dvilleneuve] 0 $ uname -a Linux fogo 2.4.21-53.ELsmp #1 SMP Wed Nov 14 03:54:12 EST 2007 i686 i686 i386 GNU/Linux to check one of our programs that also uses a 3rd party scientific calculation library. The functions cpu_has_sse2 and CPXPbar_init* come from this 3rd party library. Here is the output of calling valgrind -v on our program. ==28052== Memcheck, a memory error detector. ==28052== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==28052== Using LibVEX rev 1804, a library for dynamic binary translation. ==28052== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==28052== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==28052== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==28052== ==28052== My PID = 28052, parent PID = 21908. Prog and args are: ==28052== pbs_uni ==28052== --28052-- --28052-- Command line --28052-- pbs_uni --28052-- Startup, with flags: --28052-- --log-file=process.log --28052-- -v --28052-- Contents of /proc/version: --28052-- Linux version 2.4.21-53.ELsmp (brewbuilder@hs20-bc1-7.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-58)) #1 SMP Wed Nov 14 03:54:12 EST 2007 --28052-- Arch and hwcaps: X86, x86-sse1-sse2 --28052-- Page sizes: currently 4096, max supported 4096 --28052-- Valgrind library directory: /misc/altdev/prebuilt/i686-pc-linux_el3-gnu/valgrind-3.3.0/lib/valgrind --28052-- Reading syms from /lib/ld-2.3.2.so (0x4000000) --28052-- Reading syms from /home/cmitchelson/local/pbs-ual-2.0/pbs_ual/.GCM/i686-pc-linux_el3-gnu/t/d/pbs_uni (0x8048000) --28052-- Reading syms from /misc/altdev/prebuilt/i686-pc-linux_el3-gnu/valgrind-3.3.0/lib/valgrind/x86-linux/memcheck (0x38000000) --28052-- object doesn't have a dynamic symbol table --28052-- Reading suppressions file: /misc/altdev/prebuilt/i686-pc-linux_el3-gnu/valgrind-3.3.0/lib/valgrind/default.supp --28052-- REDIR: 0x4012140 (index) redirected to 0x38022cef (vgPlain_x86_linux_REDIR_FOR_index) --28052-- Reading syms from /misc/altdev/prebuilt/i686-pc-linux_el3-gnu/valgrind-3.3.0/lib/valgrind/x86-linux/vgpreload_core.so (0x4017000) --28052-- Reading syms from /misc/altdev/prebuilt/i686-pc-linux_el3-gnu/valgrind-3.3.0/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4019000) ==28052== WARNING: new redirection conflicts with existing -- ignoring it --28052-- new: 0x04012140 (index ) R-> 0x0401c600 index --28052-- REDIR: 0x40122e0 (strlen) redirected to 0x401c824 (strlen) --28052-- Reading syms from /lib/tls/libm-2.3.2.so (0x4030000) --28052-- Reading syms from /lib/libdl-2.3.2.so (0x4052000) --28052-- Reading syms from /lib/tls/librtkaio-2.3.2.so (0x4055000) --28052-- Reading syms from /lib/tls/libpthread-0.60.so (0x406A000) --28052-- Reading syms from /lib/tls/libc-2.3.2.so (0x407A000) --28052-- REDIR: 0x40f3fd0 (memset) redirected to 0x401d1d0 (memset) --28052-- REDIR: 0x40f2ad0 (rindex) redirected to 0x401c528 (rindex) --28052-- REDIR: 0x40eb070 (malloc) redirected to 0x401a8bc (malloc) --28052-- REDIR: 0x40f27a0 (strlen) redirected to 0x401c808 (strlen) --28052-- REDIR: 0x40f44f0 (memcpy) redirected to 0x401cb70 (memcpy) --28052-- REDIR: 0x40eb1f0 (free) redirected to 0x401b598 (free) --28052-- REDIR: 0x40f2140 (strcpy) redirected to 0x401c85c (strcpy) --28052-- REDIR: 0x40f1620 (strcmp) redirected to 0x401caa4 (strcmp) --28052-- REDIR: 0x40f4020 (mempcpy) redirected to 0x401d3cc (mempcpy) --28052-- REDIR: 0x40f2980 (strncmp) redirected to 0x401ca38 (strncmp) --28052-- REDIR: 0x40eb730 (calloc) redirected to 0x401be80 (calloc) --28052-- REDIR: 0x40f3db0 (memchr) redirected to 0x401cb4c (memchr) --28052-- REDIR: 0x40f5070 (strchrnul) redirected to 0x401d2e4 (strchrnul) --28052-- REDIR: 0x40f4190 (stpcpy) redirected to 0x401cfa8 (stpcpy) --28052-- REDIR: 0x40f14b0 (index) redirected to 0x401c5dc (index) --28052-- Reading syms from /lib/libnss_files-2.3.2.so (0x51B4000) --28052-- Reading syms from /lib/libnss_nis-2.3.2.so (0x51C0000) --28052-- Reading syms from /lib/libnsl-2.3.2.so (0x51C9000) --28052-- REDIR: 0x40f2a40 (strncpy) redirected to 0x401c914 (strncpy) --28052-- REDIR: 0x40f1300 (strcat) redirected to 0x401c648 (strcat) --28052-- REDIR: 0x40f4fa0 (rawmemchr) redirected to 0x401d300 (rawmemchr) --28052-- Reading syms from /lib/libnss_dns-2.3.2.so (0x51DE000) --28052-- Reading syms from /lib/libresolv-2.3.2.so (0x51E3000) --28052-- REDIR: 0x40eb2b0 (realloc) redirected to 0x401bf44 (realloc) --28052-- REDIR: 0x40f3f70 (memmove) redirected to 0x401d210 (memmove) --28052-- REDIR: 0x40f2850 (strnlen) redirected to 0x401c7e4 (strnlen) vex x86->IR: unhandled instruction bytes: 0x66 0x9C 0x59 0x8B ==28052== valgrind: Unrecognised instruction at address 0x83CA6CA. ==28052== Your program just tried to execute an instruction that Valgrind ==28052== did not recognise. There are two possible reasons for this. ==28052== 1. Your program has a bug and erroneously jumped to a non-code ==28052== location. If you are running Memcheck and you just saw a ==28052== warning about a bad jump, it's probably your program's fault. ==28052== 2. The instruction is legitimate but Valgrind doesn't handle it, ==28052== i.e. it's Valgrind's fault. If you think this is the case or ==28052== you are not sure, please let us know and we'll try to fix it. ==28052== Either way, Valgrind will now raise a SIGILL signal which will ==28052== probably kill your program. ==28052== ==28052== Process terminating with default action of signal 4 (SIGILL) ==28052== Illegal opcode at address 0x83CA6CA ==28052== at 0x83CA6CA: cpu_has_sse2 (in /home/cmitchelson/local/pbs-ual-2.0/pbs_ual/.GCM/i686-pc-linux_el3-gnu/t/d/pbs_uni) ==28052== by 0x83BB9EC: CPXPbar_initedcholhandle (in /home/cmitchelson/local/pbs-ual-2.0/pbs_ual/.GCM/i686-pc-linux_el3-gnu/t/d/pbs_uni) --28052-- Discarding syms at 0x51C0000-0x51C9000 in /lib/libnss_nis-2.3.2.so due to munmap() --28052-- Discarding syms at 0x51C9000-0x51DE000 in /lib/libnsl-2.3.2.so due to munmap() --28052-- Discarding syms at 0x51B4000-0x51C0000 in /lib/libnss_files-2.3.2.so due to munmap() --28052-- Discarding syms at 0x51DE000-0x51E3000 in /lib/libnss_dns-2.3.2.so due to munmap() --28052-- Discarding syms at 0x51E3000-0x51F5000 in /lib/libresolv-2.3.2.so due to munmap() ==28052== ==28052== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 29 from 2) --28052-- --28052-- supp: 10 Ugly strchr error in /lib/ld-2.3.2.so --28052-- supp: 19 Ubuntu-stripped-ld.so ==28052== malloc/free: in use at exit: 18,989,799 bytes in 29,386 blocks. ==28052== malloc/free: 43,547 allocs, 14,161 frees, 35,589,680 bytes allocated. ==28052== ==28052== searching for pointers to 29,386 not-freed blocks. ==28052== checked 17,986,312 bytes. ==28052== ==28052== LEAK SUMMARY: ==28052== definitely lost: 450 bytes in 18 blocks. ==28052== possibly lost: 895,415 bytes in 231 blocks. ==28052== still reachable: 18,093,934 bytes in 29,137 blocks. ==28052== suppressed: 0 bytes in 0 blocks. ==28052== Rerun with --leak-check=full to see details of leaked memory. --28052-- memcheck: sanity checks: 12736 cheap, 139 expensive --28052-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --28052-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 --28052-- memcheck: auxmaps_L2: 0 searches, 0 nodes --28052-- memcheck: SMs: n_issued = 495 (7920k, 7M) --28052-- memcheck: SMs: n_deissued = 6 (96k, 0M) --28052-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --28052-- memcheck: SMs: max_undefined = 3 (48k, 0M) --28052-- memcheck: SMs: max_defined = 84 (1344k, 1M) --28052-- memcheck: SMs: max_non_DSM = 489 (7824k, 7M) --28052-- memcheck: max sec V bit nodes: 6 (0k, 0M) --28052-- memcheck: set_sec_vbits8 calls: 6 (new: 6, updates: 0) --28052-- memcheck: max shadow mem size: 8128k, 7M --28052-- translate: fast SP updates identified: 59,202 ( 90.8%) --28052-- translate: generic_known SP updates identified: 3,006 ( 4.6%) --28052-- translate: generic_unknown SP updates identified: 2,939 ( 4.5%) --28052-- tt/tc: 2,051,566 tt lookups requiring 3,001,155 probes --28052-- tt/tc: 2,051,566 fast-cache updates, 8 flushes --28052-- transtab: new 31,005 (863,719 -> 13,202,318; ratio 152:10) [0 scs] --28052-- transtab: dumped 0 (0 -> ??) --28052-- transtab: discarded 719 (14,421 -> ??) --28052-- scheduler: 1,273,624,142 jumps (bb entries). --28052-- scheduler: 12,736/2,181,257 major/minor sched events. --28052-- sanity: 12737 cheap, 139 expensive checks. --28052-- exectx: 1,543 lists, 973 contexts (avg 0 per list) --28052-- exectx: 57,566 searches, 57,127 full compares (992 per 1000) --28052-- exectx: 0 cmp2, 71 cmp4, 0 cmpAll --28052-- errormgr: 8 supplist searches, 49 comparisons during search --28052-- errormgr: 29 errlist searches, 71 comparisons during search
> vex x86->IR: unhandled instruction bytes: 0x66 0x9C 0x59 0x8B This is not an SSE2 instruction, just a strange form of a "normal" one (pushfw). Try this: in VEX/priv/guest-x86/toIR.c, find this case 0x9C: /* PUSHF */ { vassert(sz == 2 || sz == 4); if (sz != 4) goto decode_failure; // XXX vassert(sz == 4); // wait for sz==2 test case // XXX [...] remove or comment out the lines marked XXX make clean make install try again. It might crash again; in which case check carefully to see if it has failed on the same instruction, or a different one. Let me know if this works / does not work.
Julian Seward wrote: > Try this: in VEX/priv/guest-x86/toIR.c, find this > > case 0x9C: /* PUSHF */ { > vassert(sz == 2 || sz == 4); > if (sz != 4) goto decode_failure; // XXX > vassert(sz == 4); // wait for sz==2 test case // XXX > [...] > > remove or comment out the lines marked XXX > try again. I did it and it crashed on a similar instruction: vex x86->IR: unhandled instruction bytes: 0x66 0x9D 0x66 0x9C I've looked into the same file and found 0x9D to be POPF, so I tried the same medicine as above. With both patches, valgrind is able to move past that point in the program. Is it safe to make this modified version available right now to my coworkers, or should I wait for the next official release? Regards, -- Daniel Villeneuve Kronos, AD OPT Division
> Is it safe to make this modified version available right > now to my coworkers, Probably. I had a quick look at the POPF stuff and it looks ok for the sz==2 case too. In any case if these instructions are not correctly implemented, it's likely the application would have died in some obvious way soon afterwards.
Fixed (vex r1835). Fix will be in 3.3.1.