|
From: Tom H. <to...@co...> - 2008-08-01 11:14:44
|
In message <D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> I guess the simplest example of this would be the following program:
>
> #include <stdlib.h>
> #include <stdio.h>
> int main()
> {
> void *p = malloc(8), *p2;
> printf("%p\n", p);
> scanf("%p", &p2);
> if (p2 == p)
> free((char*)p + 100);
> }
>
> If you enter the value printed, you get a glibc complaint. Now run
> Valgrind, enter the same value as before, and Valgrind is silent. Same
> binary, same input, but the problem is gone.
If you enter the value from the non-valgrind run, yes. If you enter
the value from the valgrind run then it complains.
> I believe this is the most common reason for cases where memory
> corruptions are not reproduced when running Valgrind.
I don't. I imagine that it's an incredibly rare case as it requires
that an address is somehow propagated from a non-valgrind run to a
valgrind run with an expectation that the address will mean something.
> So is there any chance Valgrind could ever be enhanced to maintain
> variable and heap block addresses so they match the addresses of a
> native run?
No chance whatsoever.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|