|
From: Nicholas N. <nj...@ca...> - 2003-08-05 11:32:33
|
On Tue, 5 Aug 2003, Josef Weidendorfer wrote: > Back to Valgrind: > Valgrind's SEGFAULT handler should give out a precise error message after a > SEGFAULT is catched, that this was because of application code. Obviously, > Valgrind already contains such a message when the SEGFAULT appears in Valgrind > code. The addition should be easy. Ok, would you (and Borg) be happy if instead of saying this: ==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 Segmentation fault (core dumped) Valgrind said something like: ==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. 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'm not saying the change will happen, BTW -- lots of people have used Valgrind without finding the current situation problematic. But it's good to know what is the minimum change that would fix the perceived problem :) N |