[GEMPAK #ABG-423464]: garp issues

> 
> Dear Steve,
> 
> Just to clarify below, garp does work (does not crash when hitting
> clear, reset) on the new Solaris10 with the binary 5.9.3 install. It is
> just my new Linux Fedora5 boxes having problems, which is not good for the
> new weather lab and classes starting next week. I am using the same
> datatype.tbl and garp defaults for both Solaris and Linux. The Linux has
> 2Gb of RAM and I increased the limits to unlimited, in case that was an
> issue.
> 
> Brian
> 


Brian,

The error you sent previously indicates that the problem lies within a call to
 the X library. Do you know if you are using the Xorg server/libraries on your 
FC5 boxes?

Steve Chiswell
Unidata User Support
> On Wed, 23 Aug 2006 address@hidden wrote:
> 
> >
> > Dear Steve,
> >
> > I fixed the datatype and nexrad ingest below. Thanks....
> >
> > Now I have one remaining garp problem on my linux (fedora core 5) binary
> > install version of 5.9.3. Garp loads fine and I can overlay things;
> > however, if I overlay two different types of data (surface on sat, model
> > on sat, sfc on radar, etc...) and then press clear or reset, garp crashes
> > with the error below. If I overlay within the same group (model on model)
> > and hit clear, it does not crash. Any ideas what could cause this?
> >
> > Thanks,
> >
> > Brian
> >
> > metlab>>ntl &
> > [1] 1069
> > metlab>>Resource File:  /home/gempak/GEMPAK5.9.3/resource/Ntop
> > graphic, satellite, radar, fax -- 33 95 20 2
> >  Invoke ... /home/gempak/GEMPAK5.9.3/os/linux/bin/garp
> > G A R P - v2.1 starting...
> > !!!!!Whoa!!!!!!  Free() got a 0xx
> > *** glibc detected *** /home/gempak/GEMPAK5.9.3/os/linux/bin/garp: double
> > free or corruption (!prev): 0x112304f0 ***
> > ======= Backtrace: =========
> > /lib/libc.so.6[0xb05f18]
> > /lib/libc.so.6(__libc_free+0x78)[0xb093ef]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a14c2]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x809fad8]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x809fb4e]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a0874]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a0901]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x80a80ff]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x8058695]
> > /usr/lib/libXt.so.6(XtCallCallbackList+0x123)[0x73aa63]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x82404ef]
> > /usr/lib/libXt.so.6[0x770b11]
> > /usr/lib/libXt.so.6(_XtTranslateEvent+0x2e3)[0x7711e3]
> > /usr/lib/libXt.so.6(XtDispatchEventToWidget+0x4f4)[0x748cf4]
> > /usr/lib/libXt.so.6[0x74947a]
> > /usr/lib/libXt.so.6(XtDispatchEvent+0xc7)[0x748347]
> > /usr/lib/libXt.so.6(XtAppMainLoop+0x4c)[0x7484fc]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x8051fd6]
> > /lib/libc.so.6(__libc_start_main+0xdc)[0xab7724]
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp[0x8051c51]
> > ======= Memory map: ========
> > 00101000-00109000 r-xp 00000000 fd:00 3854915
> > /usr/lib/libXrender.so.1.3.0
> > 00109000-0010a000 rwxp 00007000 fd:00 3854915
> > /usr/lib/libXrender.so.1.3.0
> > 00112000-0011b000 r-xp 00000000 fd:00 3855288
> > /usr/lib/libXcursor.so.1.0.2
> > 0011b000-0011c000 rwxp 00008000 fd:00 3855288
> > /usr/lib/libXcursor.so.1.0.2
> > 0011e000-00122000 r-xp 00000000 fd:00 3855241
> > /usr/lib/libXfixes.so.3.0.0
> > 00122000-00123000 rwxp 00003000 fd:00 3855241
> > /usr/lib/libXfixes.so.3.0.0
> > 0021f000-00235000 r-xp 00000000 fd:00 3857605    /usr/lib/libXmu.so.6.2.0
> > 00235000-00236000 rwxp 00016000 fd:00 3857605    /usr/lib/libXmu.so.6.2.0
> > 006e0000-006f0000 r-xp 00000000 fd:00 3857123    /usr/lib/libXpm.so.4.11.0
> > 006f0000-006f1000 rwxp 00010000 fd:00 3857123    /usr/lib/libXpm.so.4.11.0
> > 0072d000-00782000 r-xp 00000000 fd:00 3857482    /usr/lib/libXt.so.6.0.0
> > 00782000-00786000 rwxp 00054000 fd:00 3857482    /usr/lib/libXt.so.6.0.0
> > 007bc000-007d4000 r-xp 00000000 fd:00 3855094    /usr/lib/libg2c.so.0.0.0
> > 007d4000-007d5000 rwxp 00017000 fd:00 3855094    /usr/lib/libg2c.so.0.0.0
> > 007d5000-007d8000 rwxp 007d5000 00:00 0
> > 009e1000-009ec000 r-xp 00000000 fd:00 2219555
> > /lib/libgcc_s-4.1.1-20060525.so.1
> > 009ec000-009ed000 rwxp 0000a000 fd:00 2219555
> > /lib/libgcc_s-4.1.1-20060525.so.1
> > 00a84000-00a85000 r-xp 00a84000 00:00 0          [vdso]
> > 00a85000-00a9e000 r-xp 00000000 fd:00 2219522    /lib/ld-2.4.so
> > 00a9e000-00a9f000 r-xp 00018000 fd:00 2219522    /lib/ld-2.4.so
> > 00a9f000-00aa0000 rwxp 00019000 fd:00 2219522    /lib/ld-2.4.so
> > 00aa2000-00bcf000 r-xp 00000000 fd:00 2219538    /lib/libc-2.4.so
> > 00bcf000-00bd1000 r-xp 0012d000 fd:00 2219538    /lib/libc-2.4.so
> > 00bd1000-00bd2000 rwxp 0012f000 fd:00 2219538    /lib/libc-2.4.so
> > 00bd2000-00bd5000 rwxp 00bd2000 00:00 0
> > 00bd7000-00bfa000 r-xp 00000000 fd:00 2219545    /lib/libm-2.4.so
> > 00bfa000-00bfb000 r-xp 00022000 fd:00 2219545    /lib/libm-2.4.so
> > 00bfb000-00bfc000 rwxp 00023000 fd:00 2219545    /lib/libm-2.4.so
> > 00bfe000-00c00000 r-xp 00000000 fd:00 2219549    /lib/libdl-2.4.so
> > 00c00000-00c01000 r-xp 00001000 fd:00 2219549    /lib/libdl-2.4.so
> > 00c01000-00c02000 rwxp 00002000 fd:00 2219549    /lib/libdl-2.4.so
> > 00c04000-00cfd000 r-xp 00000000 fd:00 3854913    /usr/lib/libX11.so.6.2.0
> > 00cfd000-00d01000 rwxp 000f9000 fd:00 3854913    /usr/lib/libX11.so.6.2.0
> > 00d03000-00d08000 r-xp 00000000 fd:00 3854911
> > /usr/lib/libXdmcp.so.6.0.0
> > 00d08000-00d09000 rwxp 00004000 fd:00 3854911
> > /usr/lib/libXdmcp.so.6.0.0
> > 00d0b000-00d0d000 r-xp 00000000 fd:00 3854909    /usr/lib/libXau.so.6.0.0
> > 00d0d000-00d0e000 rwxp 00001000 fd:00 3854909    /usr/lib/libXau.so.6.0.0
> > 00d10000-00d1f000 r-xp 00000000 fd:00 3854984    /usr/lib/libXext.so.6.4.0
> > 00d1f000-00d20000 rwxp 0000e000 fd:00 3854984    /usr/lib/libXext.so.6.4.0
> > 00d3d000-00d44000 r-xp 00000000 fd:00 3860439    /usr/lib/libXp.so.6.2.0
> > 00d44000-00d45000 rwxp 00007000 fd:00 3860439    /usr/lib/libXp.so.6.2.0
> > 00d4d000-00d64000 r-xp 00000000 fd:00 3856013    /usr/lib/libICE.so.6.3.0
> > 00d64000-00d65000 rwxp 00016000 fd:00 3856013    /usr/lib/libICE.so.6.3.0
> > 00d65000-00d67000 rwxp 00d65000 00:00 0
> > 00d69000-00d71000 r-xp 00000000 fd:00 3856019    /usr/lib/libSM.so.6.0.0
> > 00d71000-00d72000 rwxp 00008000 fd:00 3856019    /usr/lib/libSM.so.6.0.0
> > 08048000-0837d000 r-xp 00000000 fd:01 44793968
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp
> > 0837d000-083a6000 rw-p 00334000 fd:01 44793968
> > /home/gempak/GEMPAK5.9.3/os/linux/bin/garp
> > 083a6000-108bf000 rw-p 083a6000 00:00 0
> > 10fb7000-11276000 rw-p 10fb7000 00:00 0          [heap]
> > b6fc6000-b7327000 rw-p b6fc6000 00:00 0
> > b7600000-b7621000 rw-p b7600000 00:00 0
> > b7621000-b7700000 ---p b7621000 00:00 0
> > b7773000-b7bee000 rw-p b7773000 00:00 0
> > b7cee000-b7eee000 r--p 00000000 fd:00 3854901
> > /usr/lib/locale/locale-archive
> > b7eee000-b7ef1000 rw-p b7eee000 00:00 0
> > b7eff000-b7f06000 r--s 00000000 fd:00 3917058
> > /usr/lib/gconv/gconv-modules.cache
> > b7f06000-b7f09000 rw-p b7f06000 00:00 0
> > bf5a4000-bf888000 rwxp bf5a4000 00:00 0          [stack]
> > bf888000-bf88b000 rw-p bf888000 00:00 0
> >
> >
> >
> >
> >
> >
> > On Fri, 18 Aug 2006, Unidata GEMPAK Support wrote:
> >
> > > >
> > > > Dear Support,
> > > >
> > > > I have two questions related to garp that was recently installed on a 
> > > > new
> > > > Sun with Solaris10.
> > > >
> > > > 1. I have done a binary install of gempak 5.9.3. It seems to be working
> > > > for the most part. It is decoding the ldm ingest (creating gem files) 
> > > > and
> > > > I can run all applications. The only problem is garp. When I hit the 
> > > > model
> > > > horiz and cross section button garp freezes and crashes with a 700 mb 
> > > > core
> > > > file. I thought it might be a garp-defaults issue (since I copied in one
> > > > I have used previously), but it also crashes with the garp-defaults that
> > > > came with gempak5.9.3. I also copied over my older 5.6.F binaries from
> > > > another Sun, and garp works fine with this, so it is something with 
> > > > 5.9.3?
> > >
> > > Brian,
> > >
> > > It may be an effect of changes since the 5.6.F distribution related to 
> > > using the
> > > datatype.tbl aliases file for model data sets rather than the 
> > > Garp_defaults
> > > pattern matching. The Garp defaults file method required all data sets be 
> > > in a single grid
> > > directory, but that isn't really feasible now, especially for larger data 
> > > sets where
> > > individual forecast times may be in seperate files. Are you using the
> > > fle naming as distributed with 5.9.3 for your LDM actions, or are you 
> > > using older
> > > configurations? Garp may get upset withe the default data set "eta" if
> > > there are no data sets that match that name (the datatype.tbl file has an 
> > > alias
> > > for eta, but it might need to be modified depending on wthere you are 
> > > using older decoder actions.
> > >
> > >
> > >
> > > >
> > > > 2. I am looking for a way to get the CONUS nexrad data into garp, so
> > > > students can overlay. I am creating  the fnexrad radar mosaic
> > > > using:
> > > > FNEXRAD ^radar_mosaic_national
> > > > PIPE    -close  decoders/dcgrib2 -d
> > > > data/gempak/logs/dcgrib_radar.log
> > > > -e GEMTBL=/home/gempak/NAWIPS/gempak/tables
> > > > data/gempak/radar/YYYYMMDD_radr.gem
> > > > #
> > > > however, since this is a gridded file, I am looking for some setup files
> > > > to display in garp (so students can overlay). Not sure if this is the 
> > > > best
> > > > approach. Actually, I was hoping that there was a CONUS NIDS ingest
> > > > directly, just like for an individual site?
> > >
> > > I create both the grib version of the radar composite as well as a gini 
> > > image in the
> > > FNEXRAD feed. The GINI image is 1km, and works well for overlaying the 
> > > image with
> > > observations, contours, watched, warnings, etc.
> > >
> > > The Grid data set can be used to plot the radar echoes on top of a 
> > > satellite image, or
> > > to use in gridded calculations (such as with the RUC temperature grids to 
> > > do a precipitation type).
> > >
> > > If you just want to look at the radar image, then the action provided in 
> > > $NAWIPS/ldm/etc/templates/pqact.gempak_nexrad is:
> > > # png compressed 1km radar GINI format
> > > FNEXRAD ^rad/NEXRCOMP/(...)/(...)_(........)_(....)
> > >         FILE    -close  data/gempak/images/sat/NEXRCOMP/\1/\2/\2_\3_\4
> > >
> > > You may prefer to put that in data/gempak/nexrad/NEXRCOMP/\1/\2/\2_\3_\4
> > > (I actually have a link on our systems)
> > > The original rational was that GINI was a satellite format, but its not a 
> > > critical issue now
> > > since the color management can handle the number of colors needed for the 
> > > echo levels.
> > >
> > > If you are using the default actions I provide, you may already be filing 
> > > these.
> > >
> > > Steve Chiswell
> > > Unidata User SUpport
> > >
> > >
> > > >
> > > > Thanks in advance for any advice.
> > > >
> > > > Brian
> > > >
> > > >
> > >
> > >
> > > Ticket Details
> > > ===================
> > > Ticket ID: ABG-423464
> > > Department: Support GEMPAK
> > > Priority: Normal
> > > Status: Closed
> > >
> > >
> >
> 
> 


Ticket Details
===================
Ticket ID: ABG-423464
Department: Support GEMPAK
Priority: Normal
Status: Closed