|
From: Nicholas N. <nj...@ca...> - 2003-08-05 10:29:43
|
On Tue, 5 Aug 2003, Vincent Penquerc'h wrote:
> > 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.
>
> Yes, that could be fixed by adding non addressable "padding"
> bytes before and after an array, I guess. Though I'm not sure
> if Valgrind could detect the creation of such an array from
> the instructions though. And it would definitely not be able
> to do so if there are more than one arrays that are merged
> together in their creation (which is just a manipulation of
> the stack pointer).
It's extremely difficult to do anything useful just by watching the stack
pointer. GCC generates code in such a way that %esp jumps all over the
place, leaving holes in the stack that aren't used, things like that. I
think the only way you can get anything sensible about the structure of
the stack is to use debug information, without it, you just can't tell
where stack arrays/variables start and end. (Static arrays are similarly
difficult. Heap-allocated arrays are trivial by comparison.)
Similarly, you can't even tell for sure when you've entered a function
just by watching the dynamic instruction stream; a 'call' instruction is
a good sign, but there are other, weirder ways of entering a function,
like jumps (used by dynamically linked libraries a lot) and things like
pushing a functions start address and doing 'ret', and other horrible
things. The best way, AFAIK, is to rely on the symbol information.
On Tue, 5 Aug 2003, Erik Corry wrote:
> > 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 just tried it, without problems, but that's probably due to GCC adding
random padding between 'a' and 'b'.
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? :)
N
|