Valgrind is stupid

=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.

>>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.