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

20030506: 20030505: 20030503: Unidata binary of nwx core dumps with surface obs

Robert,

I haven't duplicated your problem with SFC_HRLY yet....but I did find a problem
with the TAFS_DEC section where the files from the dctaf action are being named
YYYYMMDDHH_taf.gem and the nwx program is always expecting YYYYMMDD(extension)
names. So, I thought I'd verify once again that your surface files are name
YYYYMMDD_sao.gem (and don't have the hour). This also means that if you are
using the dctaf decoder and the suggested file naming, you should have the same
problem with those reports.

Basically, the first call to the directory returns an error when the file names
aren't of the expected format. The second call using the same master.tbl 
category
will skip the directory scanning for the sake of speed since the category is
the same- but doesn't know that the directory was empty.

Steve Chiswell






>From: Robert Mullenax <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200305062023.h46KNT7U020274

>> 
>
>Sorry, I should know better than to type something from memory.  You are corre
> ct.
>I have exactly what you have there.  Nothing has been modified.
>
>Robert
>> Robert,
>> 
>> I'm trying to follow your steps below, but you don't mention the same 
>> categories that I have. Lets verify:
>> 
>> 1) Open nwx
>> 2) Click on "Observed Data", you said "surface obs" which is not in my dist
>> 3) Click on "Surface Hourlies"
>> 4) Set time range
>> 5) Click on station
>> 
>> The master.tbl entry for SFC_HRLY is:
>> SFC_HRLY     sfstns.tbl   O $GEMDATA/surface                         _sao.ge
> m
>> 
>> That is expecting files named yyyymmdd_sao.gem in $GEMDATA/surface.
>> If thats not what you have, then lets see what master.tbl entries you are us
> ing.
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> 
>> >From: Unidata Support <address@hidden>
>> >Organization: UCAR/Unidata
>> 
>> >
>> >Robert,
>> >
>> >The mangling of the string below with the "dm/gempak/surface"
>> >getting tacked on seems to indicate either a string that
>> >is not properly null terminated, or is exceeding the length.
>> >The fact that certain versions usually work is probably
>> >a side affect of optimization in the compiler (less optimization
>> >sometimes keeps variables separated in memory space so that not
>> >crashing is merely fortuitous).
>> >
>> >I can look at the code and see if there is a memory problem.
>> >
>> >Steve Chiswell
>> >Unidata User Support
>> >
>> >
>> >
>> >>From: Robert Mullenax <address@hidden>
>> >>Organization: UCAR/Unidata
>> >>Keywords: 200305040336.h443aI7U004383
>> >
>> >>
>> >>In the past I have had trouble with locally built (Sun compilers SPARC and
>  x8
>> > 6
>> >>  Solaris)
>> >>versions of nwx core dumping while trying to read surface obs.  I experien
> ced
>> >>the aame thing on x86 (wxmcidas.nsbf.nasa.gov) with 5.6j, however, this ti
> me
>> >>my usual fix of getting the Unidata binary for nwx didn't work either.  It
>  al
>> > s
>> >> o core
>> >>dumps.
>> >>
>> >>I open nwx, select surface obs, click on one station and get station not f
> oun
>> > d
>> >>  (even
>> >>though it is there and sflist verifies that).  If I do nothing else all is
>  fi
>> > n
>> >> e..
>> >>if I select another station then I get these errors writen to the terminal
> :
>> >>
>> >>/export/home/gempak% nwx
>> >>Resource File:  /export/home/gempak/GEMPAK/resource/Nwx
>> >> [FL -1]  Cannot open file /var/data/ldm/gempak/surface/dm/gempak/surface.
>> >> [SF -2]  File /var/data/ldm/gempak/surface/dm/gempak/surface could not be
>  op
>> > e
>> >> ned.
>> >>Segmentation fault (core dumped)
>> >>
>> >>I have verified that Gemenviron and ~/gempak/nwx/master.tbl are correct, t
> hat
>> >  
>> >> the
>> >>data path is /var/data/ldm/gempak/surface...so it's somehow mangling
>> >>the path.
>> >>
>> >>I could go back and use an older version of nwx, but we find some of the n
> ew 
>> > f
>> >> eatures in
>> >>nwx 5.6j to be useful and nice.
>> >>
>> >>Thanks,
>> >>Robert
>> >>
>> >
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service              http://my.unidata.ucar.edu/content/support 
>> ****************************************************************************
>
>