This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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