|
From: Nicholas N. <nj...@ca...> - 2003-08-05 09:23:23
|
On Tue, 5 Aug 2003 Bor...@pd... wrote: > With the above mentioned method, the user would be sure, that this is a > bug of his program and not one of valgrind...which is really usefull Ok, this is a reasonable point. Have you used Valgrind much? Have you found this to be problem -- not being sure whether a seg fault is caused by your program or by a bug in Valgrind? Or are you new to Valgrind, and you think it might be a problem? There's an element of trust involved with using any programming tool. For example, if your program is behaving unexpectedly, do you suspect your program, or the compiler? It's a similar issue here -- at a certain level, you have to trust the tool you are using. Why should you trust it? Well, if lots of other people use it, that's a good sign. Also, if you use the tool yourself for a while, you'll soon get a feel for how trustworthy it is. > 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. I would consider the "Invalid read" message to be exactly this "message to the user". > 'Null Pointer access: Write core [c/C]? Stop execution [s/S]? Continue > on own risk [r/R]?' Valgrind can't know ahead of time whether an invalid read is actually going to cause a seg fault. Unless its a blatantly bad access, eg. to 0x0, in which case the "Invalid read" hopefully makes it pretty clear what the problem is. And with a blatantly bad access, continuing at your own risk is the same as writing core straight away. And stopping execution without producing a core file... well, that doesn't seem much more useful. Unless your program installs a SIGSEGV handler, that will complicate matters. Valgrind certainly has bugs, but from my experience it is clear when a bug is caused by Valgrind. For example, Valgrind has a SIGSEGV handler or something like that, so that on the rare occasions it seg faults itself, you get a message like "seg fault within Valgrind itself". Perhaps other people have different experiences. Also, if your program seg faults normally, and also seg faults under Valgrind, then that seems pretty clear. Sometimes your program might seg fault under Valgrind and not normally, or vice versa, due to the fact that memory gets laid out in a different way. But Valgrind's error messages should make things clear. > I really think valgrind is as great a memory checker as there is for > free to get, but it needs on some Edges a little bit more work. I'am > working in a medium sized firm, and have installed valgrind for all of > our programmers, but some of them would always seek the fault by > someone else, before thinking that they could have made a fault... Again, I think it's a matter of trust. If a programmer is sceptical, are they going be more convinced by a message that says "error in your program, really, I promise" rather than just "error in your program"? If your error message above was used, why would a sceptic believe that any more than any other error message? It too might be a bug in Valgrind (I don't think it would, but a sceptic might). > If you than only get a core for valgrind, I don't think every user will > see the bug. Sorry, I don't understand this. Do you mean cases where the program dumps core when running under Valgrind, but does not when running normally? N |