|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-05 09:21:00
|
> I think like valgrind works now it's not a well defined > behavoiur (one term > you could know out of computer science), and all it should do is print > something like the following output: It seems to be it's well defined behavior. Valgrind's behaving correctly, and then your program crashes. If you wanted to have V somehow not allow your program to crash (eg, skipping the insn), then it would really be dodgy behavior, and IMHO not Valgrind's job, which is to execute your actual program, with checks. > 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? > Continue on > own risk [r/R]?' Every program may not have a TTY. Or may have a TTY but no input. Or may run unattended. And may spew thousands of reports before the really interesting (crashing) one. etc. It could be done with an option though. > Even a simple message from valgrind like the following would make the > situation clear: > > 'Your program has caused a memory fault.' That's what it does, really. And the core is here to help you debug it. > My point is: an "Invalid read" followed by a core makes it > not always clear > if this is a bug of valgrind or the tested programm. A short > message to the > user before the core is written would make this situation more clear. If possible, then maybe. But I'm not sure V could catch every case of it. Catching signals etc may help, but this would not be very foolproof. -- Vincent Penquerc'h |