Hrvoje Niksic <hniksic(a)xemacs.org> wrote:
But how can it distinguish "slots" without analyzing source
code
which, as far as I know, valgrind doesn't do? It works for the heap
because valgrind intercepts calls to malloc, but there are no
comparable calls on the stack, at least there shouldn't be in
optimized code. For example:
int a;
int b;
int c[10];
int d;
int e;
How can valgrind know that writing to c[-1] is not a legitimate way to
modify b or d? It doesn't control how a/b/c/d/e are allocated on the
stack, the compiler does.
You are correct; it does not analyze source code, so it has no hope of
distinguishing valid accesses within a stack frame from invalid accesses
within a stack frame. My hope was that it would catch accesses to a
different stack frame (since the simulated CPU could see that a
subroutine call is being made and save the value of the old bottom of
the stack).
--
Jerry James
http://www.ittc.ku.edu/~james/