[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20040315: 20040315: 20040315: 20040314: nex2gini core dumps under Red Hat 9
- Subject: 20040315: 20040315: 20040315: 20040314: nex2gini core dumps under Red Hat 9
- Date: Mon, 15 Mar 2004 15:56:20 -0700
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 characters.
>
>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, that 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 than
>> >> >> 2MB, the uncompressed size will be 14.4 MB....but thats not the transm
> iss
>> > ion
>> >> >> size....and you don't need to uncompress in order to use the product i
> n 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 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 user 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 some ch
> ang
>> > 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 syste
> m.
>> >> >> >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 o
> n t
>> > his
>> >> > ma
>> >> >> > chine
>> >> >> >(newpsn.nsbf.nasa.gov) when it was a Red Hat 8 machine. It is now ru
> nni
>> > ng
>> >> >> >RedHat 9 and GEMPAK5.6m(Unidata binary). Now the script core dumps 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 nex2gini
>> >> >> >by hand. No luck. I got the GEMPAK5.6m code and did a source instal
> l
>> >> >> >with the same result. A GEMPAK5.6l binary also has the same core dum
> p.
>> >> >> >
>> >> >> >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 produc
> tio
>> > n
>> >> >> >server there is a Beowulf cluster running RH 7.2. nex2gini works wi
> th
>> >> >> >no problems there...GEMPAK5.6k. I copied that working RH 7.2/ GEMPAK
> 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 support to
> th
>> > e f
>> >> > olk
>> >> >> > s
>> >> >> >that are full-time at NSBF.
>> >> >> >
>> >> >> >Thanks,
>> >> >> >Robert Mullenax
>> >> >> >
>> >> >> --
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> Unidata User Support UCAR Unidata P
> rog
>> > ram
>> >> >> (303)497-8643 P.O. Bo
> x 3
>> > 000
>> >> >> address@hidden Boulder, CO
> 80
>> > 307
>> >> >> ----------------------------------------------------------------------
> ---
>> > ---
>> >> >> Unidata WWW Service http://my.unidata.ucar.edu/content/su
> ppo
>> > rt
>> >> >> ----------------------------------------------------------------------
> ---
>> > ---
>> >> >> NOTE: All email exchanges with Unidata User Support are recorded in th
> e
>> >> >> 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 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.