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

20051006: Garp problems

>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