20000313: LDM problem

David,

Linux is having trouble storing idat = (2**31)-1 in the
$GEMLIB/dp/dppgrb.f routine. All the other platforms compute 
idat as 2147483647, but Linux is generating -2147483648 from the 2**31
part of the calculation. As a result, the while loop in the code never 
converges.

The field which trips this problem is parameter 198 (cloud concentration
of ice particles) which has a range of 0 to 1.66E10 which must be scaled
to be packed in the output file.

I have respecified INT_MAX in the routine so that 2**31 - 1 doesn't have to
be calculated. A revised binary is in ~gbuddy/nawips-5.4/binary/linux
and I will repackage the linux binaries as well.

This should solve your problem since I tested it with the 18Z nggrib products
and managed to clear up the infinite loop. Let me know if you have any other 
trouble.


Steve Chiswell
Unidata User Support






>From: David Wojtowicz <address@hidden>
>Organization: .
>Keywords: 200003141817.LAA09035

>On Mon, 13 Mar 2000, Unidata Support wrote:
>
>> 
>> David,
>> 
>> It sounds to me that dcgrib may be in an infinite loop, because in general, 
> there should
>> only be one copy of dcgrib running for the ruc2 data. Since you are seeing m
> ultiple copies
>> running (that aren't exiting), the ldm is having to open another pipe to the
>  decoder
>> since the previous one isn't emptying out the pipe anymore (its pipe is full
> ).
>> I'm not seing that behavoir here on our live X86 ldm from the conduit data- 
> so it
>> may be a specific problem to linux.
>> 
>> I have two possible solutions-
>> 
>> 1) I copied a fresh "unstripped" linux executable for dcgrib into ~gbuddy/na
> wips-5.4/binary/linux
>>    The one in the binary tarfile doesn't have the debug flags, and is stripp
> ed.
>>    Can you issue a "kill -6" to dcgrib after it had been stuck for a long ti
> me?
>>    That should cause the decoder to dump core (presumably in your ~ldm home
>>    directory where the ldm was launched from). 
>>    Once the core file is created, then running 
>>    "gdb ~ldm/decoders/dcgrib ~ldm/core" and then the command "where"
>>    may tell us in what routine the decoder is hung.
>
>
>Hi Steve,
>
> Following the above instructions, here's the stack trace that
>I get.
>
>(gdb) where
>#0  0x8077d9b in pow_ri ()
>#1  0x8074dd0 in dp_pgrb__ ()
>#2  0x8070d8b in dm_pkgd__ ()
>#3  0x80667b7 in dm_wdtr__ ()
>#4  0x805f83b in gd_wpgd__ ()
>#5  0x804e466 in put_gem_grid__ (iflno=0x80d734c, centrid=0xbffff8d0,
>    gridid=0xbffff8c8, edition=0xbffff878, hasgds=0xbfffe830,
>    prmid=0xbffff8c4, lvltyp=0xbffff8c0, level1=0xbffff8bc, 
>level2=0xbffff8b8,
>    iccyr=0xbffff8a4, imonth=0xbffff8a0, iday=0xbffff89c, ihour=0xbffff898,
>    imin=0xbffff894, tunit=0xbffff890, tr1=0xbffff88c, tr2=0xbffff888,
>    trf=0xbffff884, igx=0xbffff8b4, igy=0xbffff8b0, grid=0x8546de4,
>    bits=0xbffff880, gribed=0xbffff8ac, pckflg=0x8172bf8, rlat1=0xbfffe82c,
>    rlon1=0xbfffe828, rlat2=0xbfffe824, rlon2=0xbfffe820,
>    ensext=0xbffff840 "", ensextlen=0xbfffe838, ensext_len=-1073743052)
>    at put_gem_grid.f:612
>#6  0x8049e73 in do_nc (ep=0x0, timeout=60, quasp=0x0, cdlname=0x0,
>    ncname=0xbffffc9f "/home/flood/data/conduit/YYMMDDHH_maps2_grid@@@.gem")
>    at dcgrib.c:518
>#7  0x804a586 in main (ac=11, av=0xbffffb34) at dcgrib.c:710
>#8  0x808094b in __libc_start_main (main=0x804a18c <main>, argc=11,
>    argv=0xbffffb34, init=0x80480b4 <_init>, fini=0x80c567c <_fini>,
>    rtld_fini=0, stack_end=0xbffffb2c) at ../sysdeps/generic/libc-start.c:90
>(gdb)
>
>
>
>--------------------------------------------------------
> David Wojtowicz, Research Programmer/Systems Manager
> Department of Atmospheric Sciences Computer Services
> University of Illinois at Urbana-Champaign
> email: address@hidden  phone: (217)333-8390
>--------------------------------------------------------
>
>
>