[comp.windows.x.motif] Problem destroying UIL defined widgets

rounds@interlan.Interlan.COM (dave rounds) (06/04/91)

Has anyone ever had problems destroying widgets which were defined in
UIL.  We are using Motif 1.1.1 on a Sun SPARCstation with Sun OS 4.1 
and the NeWS/X11 server.

There seems to be a problem only when the MrmNcreateCallback is used with 
an argument.  We use one creation callback routine per dialog and pass
a different tag for each widget whose id we want to use later.  In the 
callback we pickup the passed client data in a switch statement and save `
the widget id.

The widget id's are being captured correctly and can be used elsewhere.  
When the dialog is destroyed by calling XtDestroyWidget with the dialog
widget id, the program crashes.  

Using Saber-C the following warning message is obtained after 
calling  XtDestroyWidget.

Saber-C - Version 3.0  Message Panel Listing Mon Jun  3 09:11:36 1991

===============================================================================
 1 Warning:  RUN-TIME
-------------------------------------------------------------------------------
libXt.a(Alloc.o): W#98, Cannot free memory address <0x58cfac> (not at start of allocated block).

The call stack looks like this:

6 -> run
Creating program input/output window ...
Executing: a.out
(break 1) 7 -> where
error #98 (Freeing memory)
free(), builtin saber function
XtFree() at "/lib/libXt.a(Alloc.o)", pc = 0x2ecd10
UrmDestroyCallback() at "/lib/libMrm.a(Mrmwcrw.o)", pc = 0x17e87c
_XtCallCallbacks() at "/lib/libXt.a(Callback.o)", pc = 0x3dc6a0
Phase2Callbacks() at "/lib/libXt.a(Destroy.o)", pc = 0x3fde10
Recursive() at "/lib/libXt.a(Destroy.o)", pc = 0x3fddd8
Recursive() at "/lib/libXt.a(Destroy.o)", pc = 0x3fdd68
XtPhase2Destroy() at "/lib/libXt.a(Destroy.o)", pc = 0x3fe11c
_XtDoPhase2Destroy() at "/lib/libXt.a(Destroy.o)", pc = 0x3fe320
XtDispatchEvent() at "/lib/libXt.a(Event.o)", pc = 0x400ec8
XtAppMainLoop() at "/lib/libXt.a(Event.o)", pc = 0x4011b8
main(argc = (int) 1, argv = (char **) 0x1284c8) at "mdriver.c":88
saber_run((char *) 0x1500c0 "") builtin saber function
(break 1) 8 ->


If I change the code and call a separate creation callback routine
for each widget I'm interested in (without using client data), there is 
no problem.

It seems we must be doing something incredibly stupid for this to be 
happening.  Has anyone know what might be going on here.

Dave Rounds