|
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
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 10:02:07
|
On Tue, 5 Aug 2003 Bor...@pd... wrote:
> 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.
> By supervising the memory you should know when some program tries to
> dereference a NULL-Pointer.
As I said, Valgrind does tell you this:
==8495== Invalid read of size 4
==8495== at 0x804830E: main (core.c:5)
==8495== by 0x8048264: ??? (start.S:81)
==8495== Address 0x0 is not stack'd, malloc'd or free'd
Segmentation fault (core dumped)
I think your suggested message and prompt would get annoying quite
quickly; it's just repeating information. Also, Vincent made a good
point about programs for which an interactive prompt is unsuitable.
> 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>
>
> int main( int argc, char** argv )
> {
>
> int test[3];
> test[4] = 42; // out of bounds write
> printf("%d\n", test[4] );
Yes, this is an array overrun.
> char* x = "test";
> x[5] = 'x'; // the same as above
> printf("%s\n", x ); // causes memory dump
It's actually the assignment to x[5] that cause the seg fault. Run your
core file through gdb to see. The reason is that you're writing to
read-only memory. There was a thread on this mailing list about this just
the other day called "detect writing to TOC(?)". The (well, my)
conclusion was that, yes, writing to read-only memory can cause seg
faults, but they're rare and detecting them would have a big performance
cost, so it's not worth it. AFAIK, writing to read-only memory is the
only way a program can seg fault without Valgrind giving a warning first.
> return 0;
> }
>
>
> I think this are really common bugs, which would be really usefull to
> detect.
You're absolutely right, and if anyone knows how to do it without access
to the program's source code, with reasonable performance, and without
horrific complexity, we'd love to know :)
> Especially the second leads to a really bad behaviour by dumping your
> memory.
Well, the array overruns not detected by Valgrind will never cause a seg
fault. As I said, the dump for the program above is caused by writing to
read-only memory.
N
|
|
From: Erik C. <er...@ar...> - 2003-08-05 10:22:53
|
On Tue, Aug 05, 2003 at 11:02:03AM +0100, Nicholas Nethercote wrote:
>
> > Especially the second leads to a really bad behaviour by dumping your
> > memory.
>
> Well, the array overruns not detected by Valgrind will never cause a seg
> fault.
Not true:
void f()
{
char a[4];
int *b;
int c;
b = &c;
a[5] = 123;
*b = 456;
}
valgrind will tell you that the write through b is a problem,
but the real reason is the array overrun which valgrind cannot
detect, but which (indirectly) causes an array overrun.
I don't think there's any way to fix this in valgrind. Perhaps
this: http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ is what the
original poster wants. Or perhaps Java is what he really wants.
--
Erik Corry er...@ar...
|
|
From: Paul A. C. <pa...@us...> - 2003-08-05 14:48:50
|
I'd suggest that these recent threads about Valgrind not detecting/reporting invalid write attempts to read-only memory are at least justifications for adding something either to the FAQ or to the documentation (section 2.12, "Limitations"?), or both. I could take a stab at it, if someone in the project thinks it worthwhile, and nobody volunteers. (I'm not an expert in the area, but this is probably only a couple of sentences, right?) Regards, Paul Clarke On Tue, 2003-08-05 at 05:02, Nicholas Nethercote wrote: > It's actually the assignment to x[5] that cause the seg fault. Run your > core file through gdb to see. The reason is that you're writing to > read-only memory. There was a thread on this mailing list about this just > the other day called "detect writing to TOC(?)". The (well, my) > conclusion was that, yes, writing to read-only memory can cause seg > faults, but they're rare and detecting them would have a big performance > cost, so it's not worth it. AFAIK, writing to read-only memory is the > only way a program can seg fault without Valgrind giving a warning first. ... > As I said, the dump for the program above is caused by writing to > read-only memory. On Tue, 2003-08-05 at 09:10, Igmar Palsenberg wrote: > I've already requested this feature, since writing to read-only memory in > threads isn't debuggable by both gdb and valgrind. At least telling me > that the write is to read-only memory would help :) |
|
From: Nicholas N. <nj...@ca...> - 2003-08-05 15:04:01
|
On 5 Aug 2003, Paul A. Clarke wrote:
> I'd suggest that these recent threads about Valgrind not
> detecting/reporting invalid write attempts to read-only memory are at
> least justifications for adding something either to the FAQ or to the
> documentation (section 2.12, "Limitations"?), or both.
>
> I could take a stab at it, if someone in the project thinks it
> worthwhile, and nobody volunteers. (I'm not an expert in the area, but
> this is probably only a couple of sentences, right?)
Yep... how about this:
Q. My program dies with a segmentation fault, but Valgrind doesn't give
any error messages before it, or none that look related.
A. The one kind of segmentation fault that Valgrind won't give any
warnings about is writes to read-only memory. Maybe your program is
writing to a static string like this:
char* s = "hello";
s[0] = 'j';
or something similar.
Seem reasonable?
----
I've said that it's very hard/impossible to add such read-only write
checking to Valgrind's memory checker (Memcheck) without adding much
complexity and slowing it down more. However, it would be pretty easy to
write a new skin that checks specifically for this. It could be used as a
backup for Memcheck -- when you get a seg fault that Memcheck doesn't
diagnose, you could run your program through the new skin and (hopefully)
it would tell you where you wrote to read-only memory.
All this assumes that read-only writes are the only seg fault-causing
operations that Valgrind doesn't watch out for. I think this is true, but
not 100% certain.
N
|
|
From: Igmar P. <mai...@jd...> - 2003-08-06 07:52:49
|
> Yep... how about this: > > Q. My program dies with a segmentation fault, but Valgrind doesn't give > any error messages before it, or none that look related. > > A. The one kind of segmentation fault that Valgrind won't give any > warnings about is writes to read-only memory. Maybe your program is > writing to a static string like this: > > char* s = "hello"; > s[0] = 'j'; > > or something similar. > > Seem reasonable? Fine with me, if you're not experienced in debugging writing read-only mem and not knowing about it can give you a bad headache :) We might to add that writing to read-only mem makes LinuxThreads behave odd. Igmarx |
|
From: Igmar P. <mai...@jd...> - 2003-08-05 14:10:37
|
> char* x = "test";
>
> x[5] = 'x'; // the same as above
>
> printf("%s\n", x ); // causes memory dump
No, it doesn't. The cause is the x[5] = 'x';, since that is a read-only
segment in memory. I never reaches the printf(), which gdb would tell you.
I've already requested this feature, since writing to read-only memory in
threads isn't debuggable by both gdb and valgrind. At least telling me
that the write is to read-only memory would help :)
Igmar
|