|
From: Erik C. <er...@ar...> - 2003-08-05 10:53:33
|
On Tue, Aug 05, 2003 at 11:29:39AM +0100, Nicholas Nethercote wrote:
> >
> > 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 just tried it, without problems, but that's probably due to GCC adding
> random padding between 'a' and 'b'.
I think it could be because I got the stack growth direction wrong.
This one crashes like it should.
void main()
{
int *b;
char a[4];
int c;
b = &c;
a[7] = 123; // Oops!
*b = 456; // Boom!
}
> You're right, I should have been more precise: if you get a seg fault due
> to an array overrun, Valgrind will always give you some related error
> message before the seg fault happens. Any objections to that statement? :)
No objection. Valgrind gives an error message before the seg fault.
Unfortunately the error message relates to the "Boom" and not the
"Oops" line, so it's not very useful in this sort of case. The
only answer is a version of gcc with fat pointers like the one I
linked to.
By the way, I don't think Purify or Electric Fence can catch this
one either, and the nasty thing about it is that it's often a latent
bug that waits for the right (wrong) input, so you can't catch it
except by sitting down and reasoning about the program. That applies
even to Java, where you can easily get the array bounds exception far
too late (after the program started being used for real work).
--
Erik Corry er...@ar...
|