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

20020807: nex2gini dumps core occasionally, also man page correction




Pete,

The crnids core dump I believe I fixed in the zlib uncompression when
those zero length blocks were tacked on without zeroing out the memory
.....this should have been the same reason that gdradr was dumping.
If you patched the cdnids and relinked gdradr, you should be able to
relink nex2gini too.

Or, I'm trying to get 5.6.h out....but have to get a presentation together
for a trip next week....after teaching the GEMPAK workshop last week.
So getting time to put the release together is slightly difficult.
I'll update the docs too.

Chiz



On Wed, 7 Aug 2002, Pete Pokrandt wrote:

>
> Steve,
>
> First the man page correction - on the nex2gini man page, you state:
>
>    PROJ, GRDAREA, and KXKY define a grid navigation as in GDCFIL if
>    CPYFIL is blank. The GINI format has additional restrictions
>    which limit which GEMPAK projections may be used. These are,
>    LCC tangent projection (eg la1 and la2 are the same), STR, and CED.
>
> This is actually incorrect, CED is not allowed, but Mercator (MER)
> is allowed. FYI. Spent a little time figuring out why CED kept bailing
> with an invalid projection error:)
>
> Second, I have been running nex2gini here for some time, and every so
> often it dumps a core. I haven't had any time to research why, but
> I just ran a dbx on it (compiled w/o debug info so this may not help
> much) but got the following trace:
>
> Reading nex2gini
> core file header read successfully
> Reading ld.so.1
> Reading libm.so.1
> Reading libF77.so.4
> Reading libM77.so.2
> Reading libsunmath.so.1
> Reading libc.so.1
> Reading libdl.so.1
> Reading libc_psr.so.1
> program terminated by signal SEGV (Segmentation Fault)
> (dbx) where
> =>[1] _libc_kill(0x0, 0xb, 0x0, 0x0, 0x22150, 0xff30cc04), at 0xff19c840
>   [2] __f77_sigdie(0xb, 0x4c0dcf8, 0xff348d2c, 0x7064, 0xff344220, 
> 0xffbe5110),
> at 0xff30cc04
>   [3] sigacthandler(0xb, 0xffbe5110, 0xffbe4e58, 0x405b0ccc, 0xcccccccd, 
> 0x3fecc
> ccc), at 0xff19b864
>   ---- called from signal handler with signal 11 (SIGSEGV) ------
>   [4] crnids(0x4c19ed0, 0xffbe53d0, 0x0, 0xffffffc0, 0xfffffff8, 0x4e47750), 
> at
> 0xa9980
>   [5] wsatim_(0x4c19ed0, 0x3dbf310, 0x3cfd1b0, 0x3cfd170, 0x3cfd140, 
> 0x3cfd190),
>  at 0x9fb80
>   [6] hsatim_(0x4c19ed0, 0x3cfd1b0, 0x3cfd170, 0x3cfd140, 0x3cfd190, 
> 0x3cfd130),
>  at 0x9e430
>   [7] dsatim_(0x4c19ed0, 0x3cfd1b0, 0x3cfd170, 0x3cfd140, 0x3cfd190, 
> 0x3cfd130),
>  at 0x950ec
>   [8] gsatim_(0x4c19ed0, 0x38172f0, 0x84, 0x1, 0x47, 0x20), at 0x68dcc
>   [9] im_drop_(0x38172f0, 0x104c98, 0x1250c4, 0x3816270, 0x38169f8, 0x5), at 
> 0x2
> b9e4
>   [10] MAIN_(0x20, 0x2, 0x2, 0x80, 0x80, 0x80), at 0x215dc
>   [11] main(0x1, 0xffbef53c, 0xffbef544, 0x11c400, 0x0, 0x0), at 0x21eec
>
> Any ideas?  I can try to compile with debug info to get more info
> if that would help.
>
> It happens regardless of the areal extent of the gini image, but
> does not happen all the time, seemingly randomly.  I used to get
> get core dumps as well when I was using gdradr.
>
> Thanks,
>
> Pete
>
>
>
> --
> +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
> ^ Pete Pokrandt                    V 1447  AOSS Bldg  1225 W Dayton St^
> ^ Systems Programmer               V Madison,         WI     53706    ^
> ^                                  V      address@hidden       ^
> ^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
> ^ University of Wisconsin-Madison  V       262-0166 (Fax)             ^
> +<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
>