Dan Kegel wrote: > On Fri, Oct 10, 2008 at 6:17 PM, Brian Wainscott <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
