[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20051006: Garp problems
- Subject: 20051006: Garp problems
- Date: Thu, 06 Oct 2005 16:49:09 -0600
>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