20030503: Unidata binary of nwx core dumps with surface obs

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 x86
>  Solaris)
>versions of nwx core dumping while trying to read surface obs.  I experienced
>the aame thing on x86 (wxmcidas.nsbf.nasa.gov) with 5.6j, however, this time
>my usual fix of getting the Unidata binary for nwx didn't work either.  It als
> o core
>dumps.
>
>I open nwx, select surface obs, click on one station and get station not found
>  (even
>though it is there and sflist verifies that).  If I do nothing else all is fin
> 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 ope
> ned.
>Segmentation fault (core dumped)
>
>I have verified that Gemenviron and ~/gempak/nwx/master.tbl are correct, that 
> 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 new f
> eatures in
>nwx 5.6j to be useful and nice.
>
>Thanks,
>Robert
>