|
From: Joe M. <joe...@me...> - 2006-03-01 16:08:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brendan Drew wrote: > I've looked at this some more and I can't seem to contrive a simple > example. Here's what I've observed: in some cases, when using a static > variable, valgrind complains about reads / writes to those variables > upon entering their scope. To me this implies that something is going on > and it is related to static variables. Given that I've got a program Is your code threaded? It's possible a second thread is entering the function while the first thread is still initializing the statics - in that circumstance I could maybe see how valgrind would complain that the second thread is doing uninitialized memory reads. (In fact, I'm not at all sure what happens in that case - would the second thread reinitialize all the statics or try to use them partially initialized? Depends on the compiler implementation, I suppose.) > Trust me, I want these bugs fixed -- the problem is that I neither wrote > nor have access to the relevant code. What confuses me is why the code > execution would be any different --- as I've understood (and please, > educate me if I'm wrong), Valgrind uses a virtualization approach rather > than an instrumentation approach. Which means (in theory) I should see > basically identical behavior out of programs which are supposed to > display deterministic behavior. Are there subtle issues I'm not aware of > which would make this not the case? Valgrind adds red zones around each allocated block of memory to catch out-of-bounds errors, so an uninitialized pointer will point to entirely different memory under valgrind. In your case, the pointer was probably going somewhere harmless (as far as crashes go) in the regular setup, but pointing into a red zone while running under Valgrind. Also, this probably isn't happening here, but it's valgrind.h includes macros which are no-ops when running normally, but trigger behaviour in valgrind when running under it. (You can use this to make valgrind work with custom memory allocators, for example.) One of the macros returns whether or not the program was running under valgrind, so in theory the program could be running an entirely different code path depending on the return value. If your code was compiled in debug mode and the original authors used valgrind, it may use these macros. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBcb+q5NnQEnPdLcRAk3rAJ9OabynZOwNA/k1PemurfW2dffeYACbB8CX wxIgs3pEN9Cg2lVyaqjMM60= =AEkj -----END PGP SIGNATURE----- |