NOTE: The decoders
mailing list is no longer active. The list archives are made available for historical reasons.
---------- Forwarded message ---------- Date: Thu, 26 Jun 2003 10:19:49 -0600 From: Unidata Support <support@xxxxxxxxxxxxxxxx> To: rkambic@xxxxxxxxxxxxxxxx Subject: 20030625: gribtocdl memory management bug ------- Forwarded Message
To: "'support@xxxxxxxxxxxxxxxx'" <support@xxxxxxxxxxxxxxxx> From: "Donahue, John F." <john.donahue@xxxxxxx> 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
decoders
archives: