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

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



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.
>
--
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.