|
From: Brendan D. <bre...@pe...> - 2006-03-01 21:08:10
|
Joe Mason wrote: >-----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.) > > > Some portions are, yes. Although I'll admit right now that I'm surprised if this were the case. The variables are initialized as they are declared. I believe (and please, correct me if I'm wrong) that static variables which are initialized in place (e.g. static int foo = 0; ) result in the compiler emitting code which has the static variable allocated and initialized in the data section (i.e. initialized as the program is read into memory). >>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. > > Okay -- this makes a bit more sense now. Having looked at their code, I've "isolated" (if such a word is appropriate to describe the diagnosis of systematic failures which look more like terminal cancer than independent faults) several potential issues (e.g: their image representations don't all agree on whether they use 1 based or 0 based indexing. I'm willing to wager that they've mixed and matched throughout, which would explain a great deal about why the heap and stack end up trashed beyond recognition). >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. > > > I very much doubt that these folks have valgrind installed on their machines. I'll find out tomorrow when they get here and I help them install all the bits and pieces necessary to get their test harness up and running. Thanks for the heads up on this though. >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----- > > Thanks for your help! -- Brendan Drew Research Scientist PercepTek, Inc. Tel: 720-344-1037 x 126 Fax: 720-344-2360 12395 North Mead Way Littleton, CO 80125 |