[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20041230: 20041229: 20041229: 20041222: GEMPAK 5.7.4 sfgram_gf local modification trouble
- Subject: Re: 20041230: 20041229: 20041229: 20041222: GEMPAK 5.7.4 sfgram_gf local modification trouble
- Date: Fri, 20 May 2005 20:45:52 -0700
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.