Re: 20030625: gribtocdl memory management bug

NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.

On Thu, 26 Jun 2003, Unidata Support wrote:


------- 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:

John,

Thanks for the debugging the malloc problem. I really appreciate users who
take the time to look at the code. It makes it much easier then me trying
to test it on multiple platforms.  I'll incorporate it in the next
release.

Thanks,
Robb...





               /* 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



==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================


  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the decoders archives: