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

20040314: nex2gini core dumps under Red Hat 9

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20040314: nex2gini core dumps under Red Hat 9
  • Date: Sun, 14 Mar 2004 20:23:22 -0700
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 gempak.

If you have a shell script that core dumps on startup common problems are with
the number of processes on your system, or the size of the user heap being too 
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 resource 
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 reduction
>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 FNEXRAD
>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..etc
>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 appea
> 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 folk
> s
>that are full-time at NSBF.
>
>Thanks,
>Robert Mullenax
>
--
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.