CREAD buggy?

[Jack Howarth]

Jerry,
    While I can't use valgrind on MacOS X 10.4, it was pointed out to
me on the darwin-dev mailing list that I can use GuardMalloc in gdb
as a substitute. Using GuardMalloc, produces the same output as before...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00016ff0
0xffff8c84 in ___memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:189
189     /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h: No such file or directory.
        in /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h
(gdb) bt
#0  0xffff8c84 in ___memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:189
#1  0x0122f604 in *__gfortrani_format_error (f=0xbfffd366, message=0xfffffeea <Address 0xfffffeea out of bounds>) at ../../../libgfortran/io/format.c:923
#2  0x0123e2dc in formatted_transfer (type=BT_CHARACTER, p=0x4fda8, len=44) at ../../../libgfortran/io/transfer.c:431
#3  0x0123c874 in *__gfortran_transfer_character (p=0x2, len=-278) at ../../../libgfortran/io/transfer.c:884
#4  0x0003defc in cread_ (x=0xb078e9b0, y=0xb07909b0, z=0xb07929b0, wmain=0xb078a9b0, qmain=0xb078c9b0, flags=0xb247df80, segid=0xb07aecd0, res=0xb07b0cd0, resid=0xb07b2cd0, type=0xb07b4cd0, _segid=-1073752224, _res=4, _resid=4, _type=1) at coorio.f:424
#5  0x019642dc in corma2_ (islct=0xb247df80, rmsd=0xb07749b0, kcnstr=0xb07769b0, refx=0xb077a9b0, refy=0xb077c9b0, refz=0xb077e9b0, xcomp=0xb07809b0, ycomp=0xb07829b0, zcomp=0xb07849b0, wcomp=0xb07869b0, qcomp=0xb07889b0, fbeta=0xb07789b0, wmain=0xb078a9b0, qmain=0xb078c9b0, x=0xb078e9b0, y=0xb07909b0, z=0xb07929b0, dx=0xb07949b0, dy=0xb07969b0, dz=0xb07989b0, amass=0xb07a29b0) at corman.f:162
#6  0x019636b8 in corman_ () at corman.f:37
#7  0x00044e7c in xplor_parse_ (qsubshell=@0xbfffe288) at xplorFunc.f:446
#8  0x00002940 in main (argc=1, argv=0xbfffe3a0) at xplor.c:116

I have tried all the options for GuardMalloc...

     MALLOC_PROTECT_BEFORE          If this flag is set, then libgmalloc tries
                                    harder to detect buffer underruns.
                                    Specifically, libgmalloc places the mal-
                                    loc-allocated buffer at the beginning of a
                                    virtual memory page, then protects the
                                    page before.  Buffer underruns then cause
                                    an error.  The behavior without this vari-
                                    able set would be to place the buffer at
                                    the end of the page, and protect the page
                                    after.

     MALLOC_FILL_SPACE              This flag causes libgmalloc to fill the
                                    buffer with 0x55 upon creation.  This can
                                    help catch uninitialized memory problems.

     MALLOC_ALTIVEC_SIZE            Altivec requires buffers to be on 16 byte
                                    boundaries.  With this option, Guard Mal-
                                    loc ensures that the buffer starts on a 16
                                    byte boundary, and ends on the last 16
                                    bytes of the page.

So at first glance, this problem I am seeing with the READ command in
xplor-nih doesn't appear to heap corruption. Otherwise, I would have
expected it to abort the program earlier than before...

http://gcc.gnu.org/ml/fortran/2005-07/msg00495.html

Any other ideas of what to try next?
                Jack