Re: 20051006: Garp problems

Sounds good, thanks!  I'll touch base with you tomorrow.

Pete


In a previous message to me, you wrote: 

 >>From: Unidata User Support <address@hidden>
 >>Organization: Unidata Program Center/UCAR
 >>Keywords:
 >
 >Pete,
 >
 >I believe that I found a problem where Garp is using string constants in 
 >GEMPAK subroutine calls. Those GEMPAK subroutines can possibly try to modify 
 >the
 >contents of the string, eg:
 >#0  0x0011b374 in s_copy () from /usr/lib/libg2c.so.0
 >#1  0x0813acfb in st_rmbl_ ()
 >#2  0x0810db1f in dg_grid_ ()
 >#3  0x081045da in gdpdta_ ()
 >#4  0x080e5856 in pvprof_ (gdfile=0x10a36580, gdatim=0xbf98a53d, 
 >gvcord=0x10a5f869, gfunc=0x83246d4, gpoint=0x10a5f9ad, gvect=0x83246cf, 
 >    ptype=0x10a5fd79, xaxis=0x10a5fcd7, yaxis=0x10a5fd28, line=0xbf98a4ec, 
 > wind=0xbf98a58e, refvec=0x10a5fdca, winpos=0x10a5ff5f, 
 >    thtaln=0x10a5fe1b, thteln=0x10a5fe6c, mixrln=0x10a5febd, 
 > filter=0x10a5ff0e, title=0xbf98a5df, scale=0x10a5fc86, text=0xbf98a3a8, 
 >    frame=0xbf98a394, ititle=0x10a36550, verbose=0xbf98a398, iret=0xbf98a390, 
 > __g77_length_gdfile=48, __g77_length_gdatim=15, 
 >    __g77_length_gvcord=4, __g77_length_gfunc=4, __g77_length_gpoint=3, 
 > __g77_length_gvect=4, __g77_length_ptype=5, __g77_length_xaxis=5, 
 >    __g77_length_yaxis=5, __g77_length_line=5, __g77_length_wind=17, 
 > __g77_length_refvec=1, __g77_length_winpos=1, __g77_length_thtaln=6, 
 >    __g77_length_thteln=6, __g77_length_mixrln=6, __g77_length_filter=1, 
 > __g77_length_title=50, __g77_length_scale=1, __g77_length_text=11)
 >    at ../pvprof.f:213
 >#5  0x080cd66f in DisplayVerticalProfile (wo=0xd9cbfa0, mot=0x10a36540) at 
 >../displayvprof.c:102
 >#6  0x080c0b9e in ProcessDisplayList (wo=0xd9cbfa0) at ../processdsp.c:202
 >#7  0x080b1c27 in BuildVPGrid () at ../vprof.c:780
 >#8  0x080b04ac in VerticalProfileCB (w=0x1094cda8, client_data=0x0, 
 >call_data=0xbf98ba30) at ../vprof.c:410
 >#9  0x07f8a882 in XtCallCallbackList () from /usr/X11R6/lib/libXt.so.6
 >#10 0x082421bf in ActivateCommon ()
 >#11 0x07fbccaa in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6
 >#12 0x07fbd4f8 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6
 >#13 0x07f982d0 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
 >#14 0x07f98b9c in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6
 >#15 0x07f98d6a in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
 >#16 0x07f99186 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
 >#17 0x0805200c in main (argc=1, argv=0xbf98bf24) at ../main.c:155
 >
 >
 >Looking at the $GARPHOME/object/displayvprof.c routine, it hard codes the 
 >GFUNC "tmpc" and "dwpc"
 >strings as well as the GVECT "wind" paranmeter. Since those pointers will get 
 >modified in
 >the ST_RMBL roiutine, that probably makes things unhappy.
 >
 >eg:
 >pvprof( mot->filename,          tmp_datim,
 >                pot->vcoord,            "tmpc",
 >                pot->point,             "wind",
 >                pot->ptype,             pot->xaxis,
 >                pot->yaxis,             line,
 >                wind,                   pot->refvec,
 >                pot->winpos,            pot->thtaln,
 >                pot->thteln,            pot->mixrln,
 >                pot->filter,            title,
 >                pot->scale,             fontstr,
 >                &frame,                 &(mot->titleIndex),
 >                &verbose,               &iret,
 >                strlen(mot->filename),  strlen(tmp_datim),
 >                strlen(pot->vcoord),    strlen("tmpc"),
 >                strlen(pot->point),     strlen("wind"),
 >                strlen(pot->ptype),     strlen(pot->xaxis),
 >                strlen(pot->yaxis),     strlen(line),
 >                strlen(wind),           strlen(pot->refvec),
 >                strlen(pot->winpos),    strlen(pot->thtaln),
 >                strlen(pot->thteln),    strlen(pot->mixrln),
 >                strlen(pot->filter),    strlen(title),
 >                strlen(pot->scale),     strlen(fontstr) );
 >
 >I'll clean up the Garp functions and test tomorrow morning and see if this 
 >helps your cause.
 >
 >Steve
 >
 >
 >**************************************************************************** <
 >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  <
 >**************************************************************************** <


--
+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
^ Pete Pokrandt                    V 1447  AOSS Bldg  1225 W Dayton St^
^ Systems Programmer               V Madison,         WI     53706    ^
^                                  V      address@hidden       ^
^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
^ University of Wisconsin-Madison  V       262-0166 (Fax)             ^
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+