|
From: Brian W. <br...@ls...> - 2008-10-12 15:54:49
|
Dan Kegel wrote: > On Fri, Oct 10, 2008 at 6:17 PM, Brian Wainscott <br...@ls...> wrote: >> Thanks -- I'll check that out. My immediate problem is solved, in that I >> was able to use an old copy of valgrind (2.2) on an IA32 machine: it >> reported SOME uninitialized values (all in some fortran libraries which I've >> come to expect as normal). It DID report "Invalid write" which valgrind 3.3 >> did NOT report on the x86_64 platform....and fixing that fixed my problem. >> I still think there is something suspicious here, but will look into some >> of these "uninitialized values" using the --trace-origins option you >> mention. But it bothers me that valgrind 3.3 did not detect the invalid >> write, which was corrupting my heap, and valgrind 2.2 did.... > > Could be because the heap is aligned on 16 byte > boundaries for 64 bit machines, so there's > more slop allowed, as it were... > - Dan Well, I was overwriting enough memory to corrupt the heap (I was writing to the bytes before my allocation, not after) -- seems to me this should have been caught. When I did catch in on the 32 bit system, and fixed the code, it ran fine on the 64 bit system. I'll try tracking down some of the uninitialized values it now reports, using the --track-origins=yes option, and see how that goes. In this particular case it wouldn't have helped, because the array index was initialized, just holding the wrong value. -- Brian |