[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 19990308: Corrupt NGM data?

Steve,

I think I found the fix to the segmentation faults, but can't explain why it
works.  The problem seems to lie in the Garp_defaults file, under the
section where modelkeys and modellables are defined.  The problem is that if
I list modelkeys as "ngm,eta,thin,... etc" and then run garp, everything
works fine except the eta model data.  None of the defaults that I set for
eta (MapProjection, MapGarea) are picked up.  Trying to run the MSLPress_mb
function for eta 
results in messages saying "GEMPAK:  [DG -7] PMSL ^dtg @0 %NONE in SM9S"
instead of converting the PMSL to EMSL.  All other models seem fine.  If on
the other hand, I switch the modelkeys for eta to read eta.gem, it functions
properly.  Because of that, I had all the modelkeys set with the .gem
appended and that was creating problems opening the NGM.  I have the default
widget for model set to ngm, and if I tried to run the ngm first in Model
Plan View, segmentation faults occurred.  If I selected eta, then reset back
to ngm, it worked fine.  At any rate, I have the eta modelkey now set to
eta.gem and the whole program works fine.
 
MSgt Peter J. Rahe                              
Superintendent, Meteorology Lab Operations
Air Force Institute of Technology
Wright-Patterson AFB OH
e-mail  <mailto:address@hidden> address@hidden or
<mailto:address@hidden> address@hidden          
DSN 785-3636 x4646  COMM (937) 255-3636 x4646
Fax:  DSN 785-2921    COMM (937) 255-2921


        -----Original Message-----
        From:   Unidata Support [SMTP:address@hidden]
        Sent:   Wednesday, March 10, 1999 11:26 AM
        To:     Rahe Peter J MSgt AFIT/ENP
        Cc:     'address@hidden'
        Subject:        19990308: Corrupt NGM data? 

        >From: Rahe Peter J MSgt AFIT/ENP <address@hidden>
        >Organization: .
        >Keywords: 199903081552.IAA03227

        >For the last week or so, every time I try to bring up NGM model
data using
        >GARP, one of two things happens:
        >
        >       1.  The process hangs for a few minutes, then dumps a core
with
        >segmentation fault error.
        >
        >       2.  The process immediately dumps a core with segmentation
fault.
        >
        >All the other models work fine.  Is there something causing corrupt
ngm
        >data?
        >
        >Also, when I start up GARP, I get a message that says:
!!!!!Whoa!!!!!!
        >Free() got a 0x0.
        >
        >What does that mean, and how do I get rid of it?
        >MSgt Peter J. Rahe                             
        >Superintendent, Meteorology Lab Operations
        >Air Force Institute of Technology
        >Wright-Patterson AFB OH
        >e-mail  <mailto:address@hidden> address@hidden or
        ><mailto:address@hidden> address@hidden         
        >DSN 785-3636 x4646  COMM (937) 255-3636 x4646
        >Fax:  DSN 785-2921    COMM (937) 255-2921
        >

        Pete, 
        I don't see any problem with the NGM here. Are you able to run
gdinfo
        and other programs like gdcntr on the NGM file- and just GARP
crashes?
        Or is it a problem across the board with ngm?

        You might need to check your $HDS directory and make sure there are
no
        "non-gempak" files in that directory with the string "ngm" in the
name.
        When Garp pops up the menu, it looks for all files in that directory
with the 
        "ngm" string in the name to present the list of times. If it finds
something
        not recognized as a gempak grid file, that could be the problem.

        Otherwise, doublecheck your pqact.conf entry that is running dcgrib
        for the ngm data. If gdinfo doesn't show up any grids in the NGM
files,
        then the problem could be the GEMTBL directory in the dcgrib
invocation.

        The error message above (Whoa) is a check just in case the program
        tries to free unallocated memory. This shouldn't happen usually- but
        I recall that you had some problems with libraries etc on a new
system-
        this could all be related. The message is the memory check, and it
prevents
        something disasterous from happening in the unexpected case- so that
shouldn't
        cause you any problems- other than being annoying.

        Steve Chiswell
        
****************************************************************************
<
        Unidata User Support                                    UCAR Unidata
Program <
        (303)497-8644                                                  P.O.
Box 3000 <
        address@hidden                                   Boulder,
CO 80307 <
        
----------------------------------------------------------------------------
<
        Unidata WWW Service
http://www.unidata.ucar.edu/      <
        
****************************************************************************
<