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

20040315: 20040315: 20040314: nex2gini core dumps under Red Hat 9

Robert,

Can you check your NEXRIII setting in $GEMTBL/config/datatype.tbl
to make sure that the program isn't encountering any strange
characters (Tabs) etc in the line.

Since nex2gini doesn't call strstr directly, the output you show
below doesn't give me enogh to go on. Can you type "where"
at the gdb prompt to see if that will allow you to see the trail of
subroutines?

Steve Chiswell
Unidata User Support


>From: Robert Mullenax <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200403152057.i2FKvKrV019692

>It worked fine for me under 7.2 and 8.0 as well.
>
>I used input you specified below except compress=no
>and SATFIL=rad_YYYYMMDD_HHNN.
>
>I haven't used gdb in quite a while, but what I did was this:
>
>gdb nex2gini
>(gdb) run
>Then I ran nex2gini after restoring the .nts file.
>The result was:
>Program received signal SIGSEGV, Segmentation fault.
>0x4207b151 in strstr () from /lib/tls/libc.so.6
>
>Thanks very much,
>Robert Mullenax
>
>
>
>
>
>> 
>> 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 dum
> p
>> >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 transmiss
> ion
>> >> size....and you don't need to uncompress in order to use the product in g
> emp
>> > 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 bein
> g t
>> > oo small.
>> >> If you can't allocate enough room for the program array, then you would s
> ee 
>> > a dump.
>> >> If the core dump is the shell itself, then there is typically a user reso
> urc
>> > 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 chang
> es
>> >> >to take advantage of this and reduce bandwidth usage.  One important red
> uct
>> > 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 FN
> EXR
>> > AD
>> >> >feed.
>> >> >
>> >> >I an any event, I have a nex2gini script that I had used previously on t
> his
>> >  ma
>> >> > chine
>> >> >(newpsn.nsbf.nasa.gov) when it was a Red Hat 8 machine.  It is now runni
> ng
>> >> >RedHat 9 and GEMPAK5.6m(Unidata binary).  Now the script core dumps befo
> re 
>> > 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 productio
> n
>> >> >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.6
> k
>> >> >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 th
> e f
>> > olk
>> >> > s
>> >> >that are full-time at NSBF.
>> >> >
>> >> >Thanks,
>> >> >Robert Mullenax
>> >> >
>> >> --
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8643                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service              http://my.unidata.ucar.edu/content/suppo
> rt 
>> >> -------------------------------------------------------------------------
> ---
>> >> 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.
>> >
>> --
>> ****************************************************************************
>> 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.