|
From: <Bor...@pd...> - 2003-08-05 09:42:27
|
I've just started to use valgrind. But my philosophy on every program =
is,
it's better to tell the user what's the problem if you can, then to let =
him
guess where the problem lies.
I think it would be a really usefull feature for a lot of users, if you
could write a short message,
When you know that the programm will write a core.=20
By supervising the memory you should know when some program tries to
dereference a NULL-Pointer.
Till now I'am only disappointed by one point about valgrind, and that =
is the
lack of monitoring of local memory within function call. Especially =
detects
it no under or over runs for arrays.
For Example take the following program:
#include <stdio.h>=20
int main( int argc, char** argv )=20
{=20
int test[3];=20
test[4] =3D 42; // out of bounds write=20
printf("%d\n", test[4] );=20
char* x =3D "test";=20
x[5] =3D 'x'; // the same as above=20
printf("%s\n", x ); // causes memory dump=20
return 0;=20
}=20
I think this are really common bugs, which would be really usefull to
detect.
Especially the second leads to a really bad behaviour by dumping your
memory.
-----Urspr=FCngliche Nachricht-----
Von: Nicholas Nethercote [mailto:nj...@ca...]=20
Gesendet: Dienstag, 5. August 2003 11:23
An: Enders, Borg
Cc: val...@li...
Betreff: Re: AW: [Valgrind-users] core for null pointer access
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=20
> message to the user before the core is written would make this=20
> 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=20
> 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=20
> free to get, but it needs on some Edges a little bit more work. I'am=20
> working in a medium sized firm, and have installed valgrind for all =
of=20
> our programmers, but some of them would always seek the fault by=20
> 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=20
> 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
|