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

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



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 proble
> 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/lo
> 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 co
> 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 allocation
>> >> 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)(.te
> 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/~ovens
> /lo
>> > ops
>> >> >
>> >> --
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8643                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service              http://my.unidata.ucar.edu/content/suppo
> 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 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.
>
>-- 
>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
>
--
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.