Re: 20041230: 20041229: 20041229: 20041222: GEMPAK 5.7.4 sfgram_gf local modification trouble

Wow, thanks for sticking with this.  That fixed it!

David
-- 
David Ovens              e-mail: address@hidden
Research Meteorologist    phone: (206) 685-8108
Dept of Atm. Sciences      plan: Real-time MM5 forecasting for the
Box 351640                        Pacific Northwest
University of Washington          http://www.atmos.washington.edu/mm5rt
Seattle, WA  98195               Weather Graphics and Loops
                                  http://www.atmos.washington.edu/~ovens/loops

On Wed, May 18, 2005 at 01:16:57PM -0600, Unidata Support wrote:
> 
> David,
> 
> Remember this problem you were having from 12/29/2004?
> 
> The problem shown below with the core dump with call 
> sequence through sfxplt.f:67 is specific to the _gf version
> that omits the message queue (mailbox) as the gust string 'G'
> gets copied to a variable in the latter case, but when
> directly linked to the device.a library, the
> $GEMPAK/source/device/plot/dtext.f routine will modify
> the cchar string that it is passed, and the g77 compiler
> is particularly unhappy about having the constant 'G'
> changed.
> 
> A fix to sfxplt.f is to define a variable gchar, and replace the
> constant 'G' in the GTEXT call with gchar::
> 
> C*
>         CHARACTER       condtn*8, ppp*4, gchar*1
> C*
>         INCLUDE         'ERMISS.FNC'
> C*
>         DATA            gchar / 'G' /
> 
> 
> 
> and then:
> 
>                CALL GTEXT  ( 'M', xval (i), data (i), gchar, 0., 0, 0,
>      +                                  ier )
> 
> I'll search the code base for other instances where GTEXT is called with a 
> constant,
> but this is the root of your problem below.
> 
> This fix is not in the 5.8.2a release I made yesterday, but will repost
> shortly.
> 
> Steve Chiswell
> Unidata User Support
> 
> 
> >From: Unidata Support <address@hidden>
> >Organization: UCAR/Unidata
> 
> >
> >David,
> >
> >I've build a version of GEMPAK here with MMPARM=70 in
> >gemprm.h and GEMPRM.PRM and don't have an error yet.
> >
> >Can you send me your lastweek.gem file and the 
> >sfgram_gf settings you are using whe the segmentation error
> >occurs?
> >
> >Thanks,
> >Steve Chiswell
> >
> >
> >
> >>From: David Ovens <address@hidden>
> >>Organization: UCAR/Unidata
> >>Keywords: 200412291835.iBTIZRlI027804
> >
> >>Steve,  Here's the info you requested. -- David
> >>
> >>140 frosty% limit
> >>cputime         unlimited
> >>filesize        unlimited
> >>datasize        unlimited
> >>stacksize       unlimited
> >>coredumpsize    0 kbytes
> >>memoryuse       unlimited
> >>vmemoryuse      unlimited
> >>descriptors     1024 
> >>memorylocked    unlimited
> >>maxproc         7168 
> >>
> >>I have also tried 'limit stacksize 400M' but that did not help. 
> >>
> >>141 frosty% gdb sfgram_gf
> >>.....
> >> Surface file:       /tmp/lastweeksfc.gem
> >> Number of times:      49
> >> Time range:         041220/12-22/12                                 
> >> Traces: 
> >>     KOLM      dwpf:1;tmpf:1/4;2/;;10/32;50;70;90
> >>     KOLM      skyc:1.5;pmsl;wsym/4;23;32/;;5/990;1000;1010;1020;1030
> >>     KOLM      sknt;brbk;gust/4;32;2/;;5/5;10;15;20;25;30
> >>   
> >>Enter <cr> to accept parameters or type EXIT:
> >>
> >>Program received signal SIGSEGV, Segmentation fault.
> >>0x400f3364 in s_copy () from /usr/lib/libg2c.so.0
> >>(gdb) where
> >>#0  0x400f3364 in s_copy () from /usr/lib/libg2c.so.0
> >>#1  0x080ab99c in dtext_ ()
> >>#2  0x08092f68 in gtext_ ()
> >>#3  0x080519ce in sfxgst_ (parms=0x1c, icolor=0x47, ntime=0x80d785c, 
> >>    xval=0xbfffcd40, iret=0x47, __g77_length_parms=21) at sfxgst.f:59
> >>#4  0x0804d6a4 in sfxplt_ (iside=0xbfff9db8, parms=0xbfffdb10, 
> >>    prmtyp=0xbfffda30, icolor=0x80d72a0, data=0x80d7300, cdata=0x80ebb20, 
> >>    ntime=0xbfff9e2c, iptprm=0xbfffd7f0, mkcolr=0xbfff9dec, 
> >> xmndst=0xbfff9dd0
> > ,
> >>  
> >>    xval=0xbfffcd40, iret=0x47, __g77_length_parms=12, 
> >> __g77_length_prmtyp=1,
> >  
> >>    __g77_length_cdata=8) at sfxplt.f:67
> >>#5  0x0804b38c in MAIN__ () at sfgram.f:299
> >>#6  0x080c0926 in main ()
> >>#7  0x40147dc6 in __libc_start_main () from /lib/libc.so.6
> >>(gdb) 
> >>
> >>
> >>On Wed, Dec 29, 2004 at 10:58:07AM -0700, Unidata Support wrote:
> >>> 
> >>> David,
> >>> 
> >>> There are a couple of arrays in sfgram.f that are LLMXTM*MMPARM in size,
> >>> which would be 300*70 = 21,000. This type of array size isn't
> >>> found in the plan view plotting programs. One reason you may now have 
> >>> probl
> > e
> >> ms
> >>> that didn't surface with 5.6.L is that other arrays have grown as well
> >>> over time.
> >>> 
> >>> I haven't ruled out other problems yet, but it could be that
> >>> array size is too large. Can you run the program in the debugger
> >>> (compile the code with "-g" and provide me with the "where" output
> >>> of the location where the program is having the segmentation fault)
> >>> and or a trace of the program at the point of failure?
> >>> 
> >>> Please provide me with the "limit" command output and your OS,
> >>> since stacksize may be an issue here.
> >>> 
> >>> Steve Chiswell
> >>> Unidata User Support
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> >From: David Ovens <address@hidden>
> >>> >Organization: UCAR/Unidata
> >>> >Keywords: 200412291724.iBTHOjlI019118
> >>> 
> >>> >Steve,
> >>> >
> >>> >The mods were made before any build.  Older versions, 5.6.L, worked 
> >>> >fine, 
> > b
> >> ut
> >>> >not 5.7.2.  Again, sfgram_gf is the only one that fails --  sfgram,
> >>> >sfmap, sfmap_gf work fine with these files.  Suggestions?
> >>> >
> >>> >David
> >>> >-- 
> >>> >David Ovens               e-mail: address@hidden
> >>> >Research Meteorologist    phone: (206) 685-8108
> >>> >Dept of Atm. Sciences      plan: Real-time MM5 forecasting for the
> >>> >Box 351640                        Pacific Northwest
> >>> >University of Washington          http://www.atmos.washington.edu/mm5rt
> >>> >Seattle, WA  98195               Weather Graphics and Loops
> >>> >                                  
> >>> > http://www.atmos.washington.edu/~ovens/l
> > o
> >> ops
> >>> >
> >>> >On Thu, Dec 23, 2004 at 10:36:39AM -0700, Unidata Support wrote:
> >>> >> 
> >>> >> David,
> >>> >> 
> >>> >> If you have set MMPARM in both gemprm.h and GEMPRM.PRM, then
> >>> >> you have satisfied both cgemlib.a and gemlib.a.
> >>> >> 
> >>> >> Did you make the mods to a fresh build, or did you do a "make 
> >>> >> distclean"
> >>> >> to remove all libraries in $GEMLIB? Failure to do that would result in 
> >>> >> c
> > o
> >> nfl
> >>> > icts
> >>> >> between the program using one value and the library routine using
> >>> >> a different value. 
> >>> >> 
> >>> >> If the array is being crashed, it could pop up in older versions as 
> >>> >> well
> > ,
> >>> >> just dependent on how the linking order has changes the memory 
> >>> >> allocatio
> > n
> >>> >> around.
> >>> >> 
> >>> >> Steve Chiswell
> >>> >> Unidata User SUpport
> >>> >> 
> >>> >> 
> >>> >> >From: David Ovens <address@hidden>
> >>> >> >Organization: UCAR/Unidata
> >>> >> >Keywords: 200412221928.iBMJSllI020456
> >>> >> 
> >>> >> >Hello Unidata GEMPAK support (Steve),
> >>> >> >
> >>> >> >I have made modifications to GEMPRM.PRM and gempak/include/gemprm.h to
> >>> >> >change MMPARM from 40 to 70.  This has worked great in all past
> >>> >> >releases of GEMPAK with all programs.  
> >>> >> >
> >>> >> >Now, in GEMPAK 5.7.4, I have encountered a bug in sfgram_gf that is
> >>> >> >not found in sfgram.  I create a file with about a week's worth of
> >>> >> >surface data in it and then plot meteograms for 3 stations.  2 of the
> >>> >> >3 stations work fine but the 3rd causes a Segmentation fault.  Here's
> >>> >> >a breakdown of several scenarios that use this exact same file,
> >>> >> >lastweeksfc.gem, which was generated by my modified 5.7.4 code:
> >>> >> >
> >>> >> >  1) 5.7.4 sfgram (all stations fine)
> >>> >> >  2) 5.6.L sfgram and sfgram_gf (all stations fine)
> >>> >> >  3) 5.7.4 sfgram_gf (2 of the 3 are ok)
> >>> >> >
> >>> >> >I notice that the linking of programs_gf in sfgram has changed between
> >>> >> >5.6.L and 5.7.4 (due I am sure to changes in CGEMLIB and GEMLIB) and
> >>> >> >it is my belief that this is the culprit.  I think CGEMLIB which is
> >>> >> >now before the second GEMLIB linking step must have MMPARM set smaller
> >>> >> >or something like that.
> >>> >> >
> >>> >> >Attempting to compile sfgram_gf the same way as in 5.6.L leads to this
> >>> >> >error:
> >>> >> >g77 -fno-second-underscore
> >>> >> >-I/home/disk/frosty/ovens/NAWIPS-5.7.4/gempak/include
> >>> >> >-I/home/disk/frosty/ovens/NAWIPS-5.7.4/gempak/include/Linux -O
> >>> >> >sfgram.f /home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/sfgram.a
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/ginitp_alt.o
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gendp_alt.o
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gemlib.a
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gplt.a
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/device.a
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gf.a
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gn.a
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/gemlib.a
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/cgemlib.a \
> >>> >> >        -L/usr/X11R6/lib -lX11  -o
> >>> >> >      /home/disk/frosty/ovens/NAWIPS-5.7.4/bin/linux/sfgram_gf
> >>> >> >/home/disk/frosty/ovens/NAWIPS-5.7.4/lib/linux/cgemlib.a(cgrrange.o)(.t
> > e
> >> xt+
> >>> > 0xd
> >>> >> > 2):
> >>> >> >In function `cgr_range_':
> >>> >> >: undefined reference to `gqgprj_'
> >>> >> >collect2: ld returned 1 exit status
> >>> >> >make: *** [sfgram_gf] Error 1
> >>> >> >
> >>> >> >There may be numerous other *_gf program failures, but I have not
> >>> >> >found them yet.  sfplot_gf works fine with this 'lastweeksfc.gem'
> >>> >> >file, plotting data at all 3 of the stations. 
> >>> >> >
> >>> >> >Please help.
> >>> >> >
> >>> >> >Thanks and happy holidays,
> >>> >> >
> >>> >> >David
> >>> >> >-- 
> >>> >> >David Ovens            e-mail: address@hidden
> >>> >> >Research Meteorologist    phone: (206) 685-8108
> >>> >> >Dept of Atm. Sciences      plan: Real-time MM5 forecasting for the
> >>> >> >Box 351640                        Pacific Northwest
> >>> >> >University of Washington          
> >>> >> >http://www.atmos.washington.edu/mm5rt
> >>> >> >Seattle, WA  98195               Weather Graphics and Loops
> >>> >> >                                  
> >>> >> > http://www.atmos.washington.edu/~oven
> > s
> >> /lo
> >>> > ops
> >>> >> >
> >>> >> --
> >>> >> ************************************************************************
> > *
> >> ***
> >>> >> Unidata User Support                                    UCAR Unidata 
> >>> >> Pro
> > g
> >> ram
> >>> >> (303)497-8643                                                  P.O. 
> >>> >> Box 
> > 3
> >> 000
> >>> >> address@hidden                                   Boulder, CO 8
> > 0
> >> 307
> >>> >> ------------------------------------------------------------------------
> > -
> >> ---
> >>> >> Unidata WWW Service              
> >>> >> http://my.unidata.ucar.edu/content/supp
> > o
> >> rt 
> >>> >> ------------------------------------------------------------------------
> > -
> >> ---
> >>> >> NOTE: All email exchanges with Unidata User Support are recorded in the
> >>> >> Unidata inquiry tracking system and then made publicly 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 
> >>> Progra
> > m
> >>> (303)497-8643                                                  P.O. Box 
> >>> 300
> > 0
> >>> address@hidden                                   Boulder, CO 8030
> > 7
> >>> ---------------------------------------------------------------------------
> > -
> >>> 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 publicly 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.
> >>
> >>-- 
> >>David Ovens          e-mail: address@hidden
> >>Research Meteorologist    phone: (206) 685-8108
> >>Dept of Atm. Sciences      plan: Real-time MM5 forecasting for the
> >>Box 351640                        Pacific Northwest
> >>University of Washington          http://www.atmos.washington.edu/mm5rt
> >>Seattle, WA  98195               Weather Graphics and Loops
> >>                                  
> >> http://www.atmos.washington.edu/~ovens/loop
> > s
> >>
> >--
> >NOTE: All email exchanges with Unidata User Support are recorded in the
> >Unidata inquiry tracking system and then made publicly 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 publicly 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.