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