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

20040317: Never mind...Re: 20040315: 20040315: 20040315: 20040314: nex2gini core dumps under Red Hat 9



Robert,

The debug output is vitually useless when -O is used on the compile.
If you built with -g, then we might get a little further. The binary
dist was build optimized however.

Steve Chiswell


>From: Robert Mullenax <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200403171813.i2HIDurV014229

>Never mind I forgot gdb already told us all that we could find out from that.
>
>
>> Steve,
>> 
>> I got nex2gini to produce a core file this time.   Would it help if I sent
>> that to you?
>> 
>> Thanks,
>> Robert
>> 
>> > 
>> > Robert,
>> > 
>> > What is $RAD defined on your systems?
>> > Is it the same at all locations? I'm just wondering
>> > if the string is too long for something in the program.
>> > 
>> > Steve Chiswell
>> > 
>> > >From: Robert Mullenax <address@hidden>
>> > >Organization: UCAR/Unidata
>> > >Keywords: 200403152205.i2FM5drV016777
>> > 
>> > >datatype.tbl is unmodified and I check it and there are no strange charac
> ters.
>> > >
>> > >This is what I get from "where".
>> > >
>> > >(gdb) where
>> > >#0  0x4207b151 in strstr () from /lib/tls/libc.so.6
>> > >#1  0x0809dd0f in strcpy ()
>> > >
>> > >
>> > >
>> > >
>> > > 
>> > >> 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, tha
> t wou
>> > > ld 
>> > >> > 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 th
> an
>> > >> >> >> 2MB, the uncompressed size will be 14.4 MB....but thats not the t
> ransm
>> > > iss
>> > >> > ion
>> > >> >> >> size....and you don't need to uncompress in order to use the prod
> uct i
>> > > n g
>> > >> > emp
>> > >> >> > ak.
>> > >> >> >> 
>> > >> >> >> If you have a shell script that core dumps on startup common prob
> lems 
>> > > are
>> > >> >  wi
>> > >> >> > th
>> > >> >> >> the number of processes on your system, or the size of the user h
> eap b
>> > > ein
>> > >> > g t
>> > >> >> > oo small.
>> > >> >> >> If you can't allocate enough room for the program array, then you
>  woul
>> > > d s
>> > >> > ee 
>> > >> >> > a dump.
>> > >> >> >> If the core dump is the shell itself, then there is typically a u
> ser r
>> > > eso
>> > >> > 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 so
> me ch
>> > > ang
>> > >> > es
>> > >> >> >> >to take advantage of this and reduce bandwidth usage.  One impor
> tant 
>> > > red
>> > >> > uct
>> > >> >> > ion
>> > >> >> >> >in bandwidth would be to stop receiving the FNEXRAD feed and cre
> ate
>> > >> >> >> >the composites locally since we have all the radars via the PDI 
> syste
>> > > m.
>> > >> >> >> >At 14MB per file, every 5 minutes, that's a lot of bandwidth wit
> h the
>> > >  FN
>> > >> > EXR
>> > >> >> > AD
>> > >> >> >> >feed.
>> > >> >> >> >
>> > >> >> >> >I an any event, I have a nex2gini script that I had used previou
> sly o
>> > > n t
>> > >> > his
>> > >> >> >  ma
>> > >> >> >> > chine
>> > >> >> >> >(newpsn.nsbf.nasa.gov) when it was a Red Hat 8 machine.  It is n
> ow ru
>> > > nni
>> > >> > ng
>> > >> >> >> >RedHat 9 and GEMPAK5.6m(Unidata binary).  Now the script core du
> mps b
>> > > efo
>> > >> > re 
>> > >> >> > any
>> > >> >> >> > thing
>> > >> >> >> >is done.  I made sure it had write permission where the radar is
>  crea
>> > > ted
>> > >> > ..e
>> > >> >> > tc
>> > >> >> >> >and also made sure the NEXRAD data isn't corrupted and I ran nex
> 2gini
>> > >> >> >> >by hand.  No luck.  I got the GEMPAK5.6m code and did a source i
> nstal
>> > > l
>> > >> >> >> >with the same result.  A GEMPAK5.6l binary also has the same cor
> e dum
>> > > p.
>> > >> >> >> >
>> > >> >> >> >For a test I went to Universal and performed the same test on on
> e of
>> > >> >> >> >out Red Hat 9 workstations with the same result.   Our primary p
> roduc
>> > > tio
>> > >> > n
>> > >> >> >> >server there is a Beowulf cluster running RH 7.2.   nex2gini wor
> ks wi
>> > > th
>> > >> >> >> >no problems there...GEMPAK5.6k.  I copied that working RH 7.2/ G
> EMPAK
>> > > 5.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 suppo
> rt to
>> > >  th
>> > >> > e f
>> > >> >> > olk
>> > >> >> >> > s
>> > >> >> >> >that are full-time at NSBF.
>> > >> >> >> >
>> > >> >> >> >Thanks,
>> > >> >> >> >Robert Mullenax
>> > >> >> >> >
>> > >> >> >> --
>> > >> >> >> *****************************************************************
> *****
>> > > ***
>> > >> > ***
>> > >> >> >> Unidata User Support                                    UCAR Unid
> ata P
>> > > rog
>> > >> > ram
>> > >> >> >> (303)497-8643                                                  P.
> O. Bo
>> > > x 3
>> > >> > 000
>> > >> >> >> address@hidden                                   Boulde
> r, CO
>> > >  80
>> > >> > 307
>> > >> >> >> -----------------------------------------------------------------
> -----
>> > > ---
>> > >> > ---
>> > >> >> >> Unidata WWW Service              http://my.unidata.ucar.edu/conte
> nt/su
>> > > ppo
>> > >> > rt 
>> > >> >> >> -----------------------------------------------------------------
> -----
>> > > ---
>> > >> > ---
>> > >> >> >> NOTE: All email exchanges with Unidata User Support are recorded 
> in th
>> > > e
>> > >> >> >> Unidata inquiry tracking system and then made publically availabl
> e
>> > >> >> >> through the web.  If you do not want to have your interactions ma
> de
>> > >> >> >> available in this way, you must let us know in each email you sen
> d to 
>> > > us.
>> > >> >> >
>> > >> >> --
>> > >> >> ********************************************************************
> *****
>> > > ***
>> > >> >> 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 t
> o us.
>> > >> >
>> > >> --
>> > >> ***********************************************************************
> *****
>> > >> Unidata User Support                                    UCAR Unidata Pr
> ogram
>> > >> (303)497-8643                                                  P.O. Box
>  3000
>> > >> address@hidden                                   Boulder, CO 
> 80307
>> > >> -----------------------------------------------------------------------
> -----
>> > >> Unidata WWW Service              http://my.unidata.ucar.edu/content/sup
> port 
>> > >> -----------------------------------------------------------------------
> -----
>> > >> 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 u
> s.
>> > >
>> > --
>> > **************************************************************************
>> > Unidata User Support                                    UCAR Unidata Progr
>> > (303)497-8643                                                  P.O. Box 30
>> > address@hidden                                   Boulder, CO 803
>> > --------------------------------------------------------------------------
>> > Unidata WWW Service              http://my.unidata.ucar.edu/content/suppor
>> > --------------------------------------------------------------------------
>> > 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.