|
From: Jeremy F. <je...@go...> - 2003-08-05 16:50:12
|
On Tue, 2003-08-05 at 04:32, Nicholas Nethercote wrote: > ==8968== Invalid write of size 4 > ==8968== at 0x8048311: main (in /auto/homes/njn25/grind/annelid/a.out) > ==8968== by 0x8048264: ??? (start.S:81) > ==8968== Address 0x7BFFF77C is not stack'd, malloc'd or free'd > Valgrind caught a segmentation fault in your program, see last error > message for an explanation of what caused it; aborting. > > ? > > Presumably, if the client program has its own SIGSEGV handler, Valgrind > couldn't do this. Right, but it presumably has a good reason for having a SEGV handler. > One possible downside -- by not dumping core naturally, could you be > losing useful information (eg. where it happened) from the core file? I'm > not sure. Core dumps for seg faults within a client app running under > Valgrind are usually useless, though, as they occur in generated code. > Hmm. I actually do this in the syscall/signal patch. I set up a handler for all the signals which are SIG_DFL, and print a message if the result will be fatal. The obvious extension to this is to also print a stacktrace if it is a terminate w/ core signal (maybe a trace of all threads' stacks). You still need to take the signal so the process exits with the right exit code. The parent process may be relying on it. Obviously the coredump generated will be basically useless, since it is a coredump of your code as run by Valgrind, so gdb will have no idea of what to make of it. But the trace should help, along with previous messages. J |