There is a bug in the X toolkit that manifests itself on some platforms.
Here's a bug fix from Jim Huggins:
I've been investigating this problem for the last few
weeks. (where the problem is: closing child window
in motif causes core dump.)
The core dump stack is usually:
>0 0x3ff80c5f8e4 in InSharedMenupaneHierarchy() RowColumn.c:6759
#1 0x3ff80c5fc44 in SetCascadeField() RowColumn.c:6849
#2 0x3ff80c6d924 in MenuProcedureEntry() RowColumn.c:11685
#3 0x3ff80bd0a88 in Destroy() CascadeBG.c:2350
#4 0x3ff803c9d3c in Phase2Destroy() Destroy.c:113
#5 0x3ff803c9c04 in Recursive() Destroy.c:72
#6 0x3ff803c9b94 in Recursive() Destroy.c:60
#7 0x3ff803ca0b8 in XtPhase2Destroy() Destroy.c:205
#8 0x3ff803ca220 in _XtDoPhase2Destroy() Destroy.c:252
#9 0x3ff803d1a90 in XtDispatchEvent() Event.c:1127
#10 0x120026b7c in ((wxApp*)0x1400011b8)->MainLoop() wx_main.cpp:177
>From what I can tell, this is a bug in an older version
of Xt library version X11R5. I think there was a patch
for it but I have no idea what number or when it was produced.
The bug has to do with recursive destruction of Menu widgets.
(I don't know too much detail...)
I tried posting a note to comp.windows.x.intrinsics and didn't
get any working fixes or explanations. (My idea about a Xt bug
and possible patch comes from a note I found in an internal DEC
notes conference.)
I found a work around for this problem in wxWindows though:
in file srx/x/wx_item.cpp,
add the follow code to the bottom of function wxMenu::~wxMenu(void)
(I think around line 1070)
#ifdef wx_motif
if (handle) {
DestroyChildren();
wxWidgetHashTable->Delete((long)handle);
Widget w = (Widget)handle;
// XtDestroyWidget(w);
handle = NULL;
}
#endif
This is basically doing what the ~wxWin function would have done
except the XtDestroyWidget(w) has been commented out to avoid
the Xt bug. (i.e. if you uncomment that line above, the core dump
will occur.)
Jim