fbenz / fpdebug Goto Github PK

I cross-compiled the Valgrind-3.11.0 to test my program on mips32 GNU/Linux.
the configure script
./configure --host=mipsel-linux-gnu CC=mipsel-linux-gcc CXX=mipsel-linux-g++ --program-prefix=mipsel-linux- --prefix=/home/long/valgrind

the command
./mipsel-linux-valgrind --tool=memcheck --leak-check=full ./test

But then when I tested the program I got the following error.As I know there are 2 reasons for this:
1.There are some bugs in my program.(the program runs well without the valgrind test)
2.The valgrind can't recognise some specific instructions.(if it's this reason, how to solve it? the latest valgrind release doesn't resolve it.)

vex mips->IR: unhandled instruction bytes: 0x2 0x0 0x83 0x44
==9150== valgrind: Unrecognised instruction at address 0x4ae67e0.
==9150== at 0x4AE67E0: bestBtreeIndex (sqlite3.c:105772)
==9150== by 0x4B0CC0C: sqlite3WhereBegin (sqlite3.c:107563)
==9150== by 0x4B11B84: sqlite3Select (sqlite3.c:98432)
==9150== by 0x4B34730: yy_reduce (sqlite3.c:110363)
==9150== by 0x4B34730: sqlite3Parser (sqlite3.c:111348)
==9150== by 0x4B38AD8: sqlite3RunParser (sqlite3.c:112185)
==9150== by 0x4B392A0: sqlite3Prepare (sqlite3.c:94032)
==9150== by 0x4B3990C: sqlite3LockAndPrepare (sqlite3.c:94124)
==9150== by 0x4B3BAA4: sqlite3_prepare (sqlite3.c:94188)
==9150== by 0x4B26678: sqlite3_exec (sqlite3.c:90569)
==9150== by 0x4B27740: sqlite3InitOne (sqlite3.c:93752)
==9150== by 0x4B27A38: sqlite3Init (sqlite3.c:93818)
==9150== by 0x4B27BA4: sqlite3ReadSchema (sqlite3.c:93855)
==9150== Your program just tried to execute an instruction that Valgrind
==9150== did not recognise. There are two possible reasons for this.
==9150== 1. Your program has a bug and erroneously jumped to a non-code
==9150== location. If you are running Memcheck and you just saw a
==9150== warning about a bad jump, it's probably your program's fault.
==9150== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9150== i.e. it's Valgrind's fault. If you think this is the case or
==9150== you are not sure, please let us know and we'll try to fix it.
==9150== Either way, Valgrind will now raise a SIGILL signal which will
==9150== probably kill your program.
==9150==
==9150== Process terminating with default action of signal 4 (SIGILL)
==9150== Illegal opcode at address 0x4AE67E0
==9150== at 0x4AE67E0: bestBtreeIndex (sqlite3.c:105772)
==9150== by 0x4B0CC0C: sqlite3WhereBegin (sqlite3.c:107563)
==9150== by 0x4B11B84: sqlite3Select (sqlite3.c:98432)
==9150== by 0x4B34730: yy_reduce (sqlite3.c:110363)
==9150== by 0x4B34730: sqlite3Parser (sqlite3.c:111348)
==9150== by 0x4B38AD8: sqlite3RunParser (sqlite3.c:112185)
==9150== by 0x4B392A0: sqlite3Prepare (sqlite3.c:94032)
==9150== by 0x4B3990C: sqlite3LockAndPrepare (sqlite3.c:94124)
==9150== by 0x4B3BAA4: sqlite3_prepare (sqlite3.c:94188)
==9150== by 0x4B26678: sqlite3_exec (sqlite3.c:90569)
==9150== by 0x4B27740: sqlite3InitOne (sqlite3.c:93752)
==9150== by 0x4B27A38: sqlite3Init (sqlite3.c:93818)
==9150== by 0x4B27BA4: sqlite3ReadSchema (sqlite3.c:93855)
==9150==
==9150== HEAP SUMMARY:
==9150== in use at exit: 79,516 bytes in 73 blocks
==9150== total heap usage: 352 allocs, 279 frees, 99,025 bytes allocated
==9150==
==9150== 1,184 bytes in 1 blocks are possibly lost in loss record 61 of 65
==9150== at 0x48A7C14: malloc (vg_replace_malloc.c:299)
==9150== by 0x4B52C80: sqlite3MemMalloc (sqlite3.c:15551)
==9150== by 0x4AAB36C: mallocWithAlarm (sqlite3.c:18849)
==9150== by 0x4AAB6A8: sqlite3Malloc (sqlite3.c:18882)
==9150== by 0x4AAED80: pcache1Alloc (sqlite3.c:35860)
==9150== by 0x4ACB150: pcache1AllocPage (sqlite3.c:35944)
==9150== by 0x4ACB150: pcache1Fetch (sqlite3.c:36447)
==9150== by 0x4AC641C: sqlite3PcacheFetch (sqlite3.c:35271)
==9150== by 0x4AF353C: sqlite3PagerAcquire (sqlite3.c:42372)
==9150== by 0x4AF379C: btreeGetPage (sqlite3.c:49869)
==9150== by 0x4B15B10: lockBtree (sqlite3.c:50644)
==9150== by 0x4B15B10: sqlite3BtreeBeginTrans (sqlite3.c:50956)
==9150== by 0x4B27830: sqlite3InitOne (sqlite3.c:93646)
==9150== by 0x4B27A38: sqlite3Init (sqlite3.c:93818)
==9150==
==9150== LEAK SUMMARY:
==9150== definitely lost: 0 bytes in 0 blocks
==9150== indirectly lost: 0 bytes in 0 blocks
==9150== possibly lost: 1,184 bytes in 1 blocks
==9150== still reachable: 78,332 bytes in 72 blocks
==9150== of which reachable via heuristic:
==9150== length64 : 76,280 bytes in 71 blocks
==9150== suppressed: 0 bytes in 0 blocks
==9150== Reachable blocks (those to which a pointer was found) are not shown.
==9150== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==9150==
==9150== For counts of detected and suppressed errors, rerun with: -v
==9150== Use --track-origins=yes to see where uninitialised values come from
==9150== ERROR SUMMARY: 162 errors from 7 contexts (suppressed: 1 from 1)
Illegal instruction

Why do I enter --tool=fpdebug, it shows failed to start tool 'fpdebug' for platform 'amd64-linux', if you can answer me, thank you very much

I managed to compile this using your instructions and additionally modifying the configure script to accept the kernel version and gcc version of ubuntu 16.04. But then when I tested it on the example I got the following error.

==26562== FpDebug-0.1, Floating-point arithmetic debugger
==26562== Copyright (C) 2010-2011 by Florian Benz.
==26562== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==26562== Command: fpdebug/examples/test_1.out
==26562==
==26562== precision=120
==26562== mean-error=yes
==26562== ignore-libraries=no
==26562== ignore-accurate=yes
==26562== sim-original=no
==26562== analyze-all=yes
==26562== bad-cancellations=yes
==26562== ignore-end=no
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1B 0x84 0x24 0x80 0x0 0x0
==26562== valgrind: Unrecognised instruction at address 0x4017cee.
==26562== at 0x4017CEE: _dl_runtime_resolve_sse (dl-trampoline.h:93)
==26562== Your program just tried to execute an instruction that Valgrind
==26562== did not recognise. There are two possible reasons for this.
==26562== 1. Your program has a bug and erroneously jumped to a non-code
==26562== location. If you are running Memcheck and you just saw a
==26562== warning about a bad jump, it's probably your program's fault.
==26562== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26562== i.e. it's Valgrind's fault. If you think this is the case or
==26562== you are not sure, please let us know and we'll try to fix it.
==26562== Either way, Valgrind will now raise a SIGILL signal which will
==26562== probably kill your program.
==26562==
==26562== Process terminating with default action of signal 4 (SIGILL)
==26562== Illegal opcode at address 0x4017CEE
==26562== at 0x4017CEE: _dl_runtime_resolve_sse (dl-trampoline.h:93)
==26562==
==26562== SHADOW VALUES (fpdebug/examples/test_1.out_shadow_values_relative_error_5): successful
==26562== SHADOW VALUES (fpdebug/examples/test_1.out_shadow_values_canceled_5): successful
==26562== SHADOW VALUES (fpdebug/examples/test_1.out_shadow_values_special_5): successful
==26562== MEAN ERRORS (fpdebug/examples/test_1.out_mean_errors_addr_5): successful
==26562== MEAN ERRORS (fpdebug/examples/test_1.out_mean_errors_canceled_5): successful
==26562== MEAN ERRORS (fpdebug/examples/test_1.out_mean_errors_intro_5): successful
==26562== DEBUG - Client exited with code: 0
--26562-- DEBUG - SBs: 1,362, executed: 16,153, instr: 48,945
--26562-- DEBUG - ShadowValues (frees/mallocs): 0/0, diff: 0
--26562-- DEBUG - Floating-point operations: 0
--26562-- DEBUG - Max temps: 201
--26562-- OPTIMIZATION - GET: total 3,358, ignored: 196
--26562-- OPTIMIZATION - STORE: total 1,372, ignored: 0
--26562-- OPTIMIZATION - PUT: total 12,159, ignored: 3,774
--26562-- OPTIMIZATION - LOAD: total 1,922, ignored: 0
Illegal instruction

Hi there,

Apologies if this is not the right place to ask a "support" question.

I am hoping to use FpDebug to track down a pretty nasty bug plaguing a system I am working on (3D vision specifically) which I think might be caused by floating point precision. I managed to build FpDebug and launch the application with valgrind, however I hit straight away the assert tl_assert(tmp >= 0 && tmp < MAX_TEMPS);. Am I right to think that is some limit on the application size that FpDebug might work with? Notice that my app is fairly large (roughly 60k lines of code).

Many thanks!
Emanuele