20030625: gribtocdl memory management bug (fwd)

---------- Forwarded message ----------
Date: Thu, 26 Jun 2003 10:19:49 -0600
From: Unidata Support <address@hidden>
To: address@hidden
Subject: 20030625: gribtocdl memory management bug


------- Forwarded Message

>To: "'address@hidden'" <address@hidden>
>From: "Donahue, John F." <address@hidden>
>Subject: gribtocdl memory management bug
>Organization: Nothrop Grumman Inforamtion Technology
>Keywords: 200306261546.h5QFkDLd005995 gribtocdl

Dear Unidata,
        We are  using some of your software for a Air Force project.  The
centerpiece of it your IDV. We are using gribtocdl to decode GRIB files into
netCDF format for IDV input. We have had to do some modification to
gribtocdl because the GRIB tables used by the Air Force Weather Agency is
different from that used by NCEP. (The Navy's is different still.) We had
our modified code working successfully on a Linux-based PC, using gcc 3.0.2
and Red Hat 7.2.  When we upgraded to a new computer using Red Hat 8.0 and
gcc 3.2, gribtocdl would hang in emalloc.
        Using the dmalloc memory debugger I found a piece of code where a
chunk of memory had been freed twice. This is in get_prod.c, which was not
touched by us, so it may affect all your users..

I've reproduced the affected code below, with our mods. We just commented
out at two line if statement at the end of get_prod.c:

               /* We only get here if EOF read, so exit gracefully  */
                uinfo("EOF on input");
                /* new code by Terje */
/* Modified by NGIT because a pointer was being freed twice. */
/*              if(prodp->id)
                   free(prodp->id); */
                TEST_NOSERC( "FOUND_EOF", 121 );
                return -1;
                /* exit(0); */
            }

Once I commented out those lines, everything ran fine.

John Donahue
Meterologist
Nothrop Grumman Inforamtion Technology
Reading, MA 617-630-9750




------- End of Forwarded Message