=20773== Process terminating with default action of signal 11 (SIGSEGV)
==20773== Access not within mapped region at address 0x4
==20773== at 0x804AD01: gpvm_int_arith (in /usr/bin/gpvm)
==20773== by 0x4076482: (below main) (in /lib/libc-2.15.so)
==20773== If you believe this happened as a result of a stack
==20773== overflow in your program's main thread (unlikely but
==20773== possible), you can try to increase the size of the
==20773== main thread stack using the --main-stacksize= flag.
==20773== The main thread stack size used in this run was 8388608.
==20773==
==20773== HEAP SUMMARY:
==20773== in use at exit: 3,310 bytes in 139 blocks
==20773== total heap usage: 169 allocs, 30 frees, 4,242 bytes allocated
==20773==
==20773== LEAK SUMMARY:
==20773== definitely lost: 32 bytes in 2 blocks
==20773== indirectly lost: 0 bytes in 0 blocks
==20773== possibly lost: 2,015 bytes in 1 blocks
==20773== still reachable: 1,263 bytes in 136 blocks
==20773== suppressed: 0 bytes in 0 blocks
==20773== Rerun with --leak-check=full to see details of leaked memory
==20773==
==20773== For counts of detected and suppressed errors, rerun with: -v
==20773== Use --track-origins=yes to see where uninitialised values come from
==20773== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault
And yet, the program executes as long after that point as it wants to (Until it's done, usually). I think valgrind caught it's own segfault; see the final line.
>>1 I have plenty of programs crash when running in a debugger or memory checker but (appear) to run normally without. A memory error wont necessarily have a detectable effect in a test run. If the application is complex, then it will likely show up eventually.
Name:
Anonymous2012-03-07 14:51
>>2
I've had silent segfaults before, but this keeps running like a champ and that function is called hundreds of times per second. I just hope it's not something sinister. Memory corruption is a bitch.
Name:
Anonymous2012-03-07 15:48
You're an idiot.
Name:
Anonymous2012-03-07 23:50
>>3 it always is both sinister, and a bitch. Or it can never have a visible effect in your tests or your platform in general, and then come up elsewhere. Such is the life of a c programmer.
Name:
Anonymous2012-03-08 1:45
this is what you get for not using node.js
Name:
Anonymous2012-03-08 1:58
Read SICP. It'll teach you how to eliminate even the possibility segfault.
Name:
Anonymous2012-03-08 4:11
/prog/ was right about something for once. The segfault just reared its ugly head.
Valgrind is awesome. Here are the results from the Scheme interpreter I wrote in C when run on a script that takes the derivative of an expression and simplifies it.
$ valgrind ss matcher-from-lecture.scm
==3185== Memcheck, a memory error detector
==3185== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3185== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==3185== Command: ss matcher-from-lecture.scm
==3185==
(dd (+ (* a (** x 2)) (+ (* b x) x)) x)
(+ (+ (* a (* (* 2 (+ x 1)) 1)) (* 0 (** x 2))) (+ (+ (* b 1) (* 0 x)) 1))
(+ 1 (+ (* 2 a) (+ (* 2 (* a x)) b)))
==3185==
==3185== HEAP SUMMARY:
==3185== in use at exit: 0 bytes in 0 blocks
==3185== total heap usage: 344,030 allocs, 344,030 frees, 10,802,643 bytes allocated
==3185==
==3185== All heap blocks were freed -- no leaks are possible
==3185==
==3185== For counts of detected and suppressed errors, rerun with: -v
==3185== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6)
>>9 (suppressed: 13 from 6)
What feel would that be? I should also mention that this is discussed in SICP, so it's not like writing an ANSI C compiler or anything.
Name:
Anonymous2012-03-08 9:17
Can Valgrind check your code for doubles?
Name:
Anonymous2012-03-08 11:40
I love Valgrind.
>>2
More annoying is when it's the other way around, and the program is bug-free with the debugger. It's a bit like the observer effect in quantum physics.