|
From: Alex B. <ker...@be...> - 2006-09-07 14:26:52
|
On Thu, 2006-09-07 at 15:09 +0100, Tom Hughes wrote: > In message <115...@ok...> > Alex Bennee <ker...@be...> wrote: > > Additionally running the program native with the instrumentation never > > clobbers the pid variable to 0. I think this points more towards a a bug > > with Valgrind. > > I think it's very unlikely. I can't think of a single case of such a > bug in valgrind where it was wrongly writing to client memory. > > Or are you suggesting a translation error so that valgrind is > producing incorrect code? Those are pretty rare as well... > > Far more likely is that running under valgrind has changed the > layout of memory in your program so that an existing problem in > your program is manifesting itself by overwriting something more > important. Could be I guess. But that still leads to the initial problem of how do identify the thing that is clobbering the variable. The value itself is stored in a uint32_t so I tried adding a uint16_t in front of it to see if it was getting lucky doing a 32 bit write into that address. However nothing came up from that. Setting the variable to a 64 bit one didn't pick up a rouge 32 bit write either (if valgrind would pick that up?). > > > Is there a way to log the loads and stores valgrind makes? > > No. I'm not even entirely sure what loads and stores you are talking > about, but the answer is no anyway. Well something is writing the memory. As we known the address of the memory in question is there a way to hook into valgrind and ask it "let me know the 2nd time a value is written to this address"? > > Tom > -- Alex, homepage: http://www.bennee.com/~alex/ WARNING TO ALL PERSONNEL: Firings will continue until morale improves. |