|
From: Michael A. <Mic...@fs...> - 2007-04-06 08:43:16
|
Hello folks, hello Martin, hello Jason, before I get to my problem let me thank you for a excellent piece of software. Valgrind has saved me lots of time over and over again. I would consider it the most important piece of debugging tools in my arsenal. I just got the following problem when valgrinding a gmp-4.2.1 with Jason Martin's CoreDuo patch with the 3.2.3 release: vex amd64->IR: unhandled instruction bytes: 0x9F 0x49 0x89 0xC9 After checking out current SVN (3.3.0SVN according to --version) from today I reran the test and I still got the same problem. I couldn't find anything useful in the archives. Because Jason's Core Duo patch uses hand crafted assembly code to speed up the gmp for CoreDuos and the standard gmp has no such problems I cc'ed him as well as Martin since he pointed out that problem to me yesterday in private conversation. To reproduce: Get a gmp-4.2.1, get Jason Martin's CoreDuo patch from http://www.math.jmu.edu/~martin/gmp-4.2.1-core2-port.tar.gz Apply that patch on a CoreDuo and build the gmp, make check so that all the tests are run an build. Then use memcheck on t-sub (which is somewhere in the test directory after "make check". Let me know if I can help you any other way or if I got this all completely wrong and it is my fault ;) Cheers, Michael The complete output was: /tmp/Work/gmp-test>/tmp/Work/valgrind-20070406-svn/bin/valgrind --tool=memcheck --leak-resolution=high --show-reachable=yes ./t-sub ==15593== Memcheck, a memory error detector. ==15593== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==15593== Using LibVEX rev 1748, a library for dynamic binary translation. ==15593== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==15593== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==15593== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==15593== For more details, rerun with: -v ==15593== vex amd64->IR: unhandled instruction bytes: 0x9F 0x49 0x89 0xC9 ==15593== valgrind: Unrecognised instruction at address 0x40E135. ==15593== Your program just tried to execute an instruction that Valgrind ==15593== did not recognise. There are two possible reasons for this. ==15593== 1. Your program has a bug and erroneously jumped to a non-code ==15593== location. If you are running Memcheck and you just saw a ==15593== warning about a bad jump, it's probably your program's fault. ==15593== 2. The instruction is legitimate but Valgrind doesn't handle it, ==15593== i.e. it's Valgrind's fault. If you think this is the case or ==15593== you are not sure, please let us know and we'll try to fix it. ==15593== Either way, Valgrind will now raise a SIGILL signal which will ==15593== probably kill your program. ==15593== ==15593== Process terminating with default action of signal 4 (SIGILL) ==15593== Illegal opcode at address 0x40E135 ==15593== at 0x40E135: __gmpn_add_n (in /tmp/Work/gmp-test/t-sub) ==15593== by 0x40A40D: __gmpf_sub (in /tmp/Work/gmp-test/t-sub) ==15593== by 0x4014E3: check_rand (in /tmp/Work/gmp-test/t-sub) ==15593== by 0x401728: main (in /tmp/Work/gmp-test/t-sub) ==15593== ==15593== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==15593== malloc/free: in use at exit: 2,916 bytes in 16 blocks. ==15593== malloc/free: 18 allocs, 2 frees, 2,964 bytes allocated. ==15593== For counts of detected errors, rerun with: -v ==15593== searching for pointers to 16 not-freed blocks. ==15593== checked 79,872 bytes. ==15593== ==15593== LEAK SUMMARY: ==15593== definitely lost: 0 bytes in 0 blocks. ==15593== possibly lost: 0 bytes in 0 blocks. ==15593== still reachable: 2,916 bytes in 16 blocks. ==15593== suppressed: 0 bytes in 0 blocks. ==15593== Rerun with --leak-check=full to see details of leaked memory. Illegal instruction |