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

20040315: 20040314: nex2gini core dumps under Red Hat 9

Robert,

I've run nex2gini under 7.3 and fedora without problems.

 GRDAREA  = 23;-120;47.2634;-63.5664
 PROJ     = lcc/40;-100;40
 KXKY     = 4736;3000
 CPYFIL   =  
 GFUNC    = n0r
 RADTIM   = current
 RADDUR   = 30
 RADFRQ   =  
 STNFIL   = nexrad.tbl
 RADMODE  = pc
 SATFIL   = test.gini
 COMPRESS = yes
 GEMPAK-NEX2GINI>

If you can send me the parameter input you are using, I can look at it.
The above input for garea and proj can be found in the 
$NAWIPS/unidata/programs/nex2gini/nex2gini.nts file as well.

Make sure you have a valid GINI projection specified.

Also, if you can send me the gdb output of where the program is, that would 
help.

Steve Chiswell



>From: Robert Mullenax <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200403150619.i2F6J1rV017641

>Steve,
>
>I didn't know that product was compressed.    Thanks.  
>
>I am not imposing any limits,  I am just using OS defaults.  limit says:
>cputime         unlimited
>filesize        unlimited
>datasize        unlimited
>stacksize       8192 kbytes
>coredumpsize    unlimited
>memoryuse       unlimited
>vmemoryuse      unlimited
>descriptors     1024
>memorylocked    unlimited
>maxproc         7168
>
>On the RH7.2 system where it works fine it's the same:
>cputime         unlimited
>filesize        unlimited
>datasize        unlimited
>stacksize       8192 kbytes
>coredumpsize    unlimited
>memoryuse       unlimited
>descriptors     1024
>memorylocked    unlimited
>maxproc         7168
>openfiles       1024
>
>Both RH 9 systems I tried it on were nearly idle.    
>Just for the heck of it I set stacksize to 75000 and I still get a core dump
>with running the shell script or running nex2gini by hand.
>
>Thanks,
>Robert
>
>
>
>
>
>
>
>
>> 
>> Robert,
>> 
>> The 1km Noational mosaic I create is compressed and today less than
>> 2MB, the uncompressed size will be 14.4 MB....but thats not the transmission
>> size....and you don't need to uncompress in order to use the product in gemp
> ak.
>> 
>> If you have a shell script that core dumps on startup common problems are wi
> th
>> the number of processes on your system, or the size of the user heap being t
> oo small.
>> If you can't allocate enough room for the program array, then you would see 
> a dump.
>> If the core dump is the shell itself, then there is typically a user resourc
> e issue.
>> 
>> Have you imposed user limits on your generating process?
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> 
>> >From: Robert Mullenax <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200403142257.i2EMvIrV005219
>> 
>> >
>> >NSBF recently obtained a PDI NOAAport system and I was making some changes
>> >to take advantage of this and reduce bandwidth usage.  One important reduct
> ion
>> >in bandwidth would be to stop receiving the FNEXRAD feed and create
>> >the composites locally since we have all the radars via the PDI system.
>> >At 14MB per file, every 5 minutes, that's a lot of bandwidth with the FNEXR
> AD
>> >feed.
>> >
>> >I an any event, I have a nex2gini script that I had used previously on this
>  ma
>> > chine
>> >(newpsn.nsbf.nasa.gov) when it was a Red Hat 8 machine.  It is now running
>> >RedHat 9 and GEMPAK5.6m(Unidata binary).  Now the script core dumps before 
> any
>> > thing
>> >is done.  I made sure it had write permission where the radar is created..e
> tc
>> >and also made sure the NEXRAD data isn't corrupted and I ran nex2gini
>> >by hand.  No luck.  I got the GEMPAK5.6m code and did a source install
>> >with the same result.  A GEMPAK5.6l binary also has the same core dump.
>> >
>> >For a test I went to Universal and performed the same test on one of
>> >out Red Hat 9 workstations with the same result.   Our primary production
>> >server there is a Beowulf cluster running RH 7.2.   nex2gini works with
>> >no problems there...GEMPAK5.6k.  I copied that working RH 7.2/ GEMPAK5.6k
>> >nex2gini binary to the workstation and nex2gini still core dumps.  So it ap
> pea
>> > rs
>> >to be an issue with Red Hat 9.
>> >
>> >Any ideas?  Would you like for me to send one of the core files?
>> >
>> >Please reply to all as we are trying to transition primary support to the f
> olk
>> > s
>> >that are full-time at NSBF.
>> >
>> >Thanks,
>> >Robert Mullenax
>> >
>> --
>> ****************************************************************************
>> 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 
>> ----------------------------------------------------------------------------
>> NOTE: All email exchanges with Unidata User Support are recorded in the
>> Unidata inquiry tracking system and then made publically available
>> through the web.  If you do not want to have your interactions made
>> available in this way, you must let us know in each email you send to us.
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.