From a thread starting here:
>I just got a freezing NEdit:
>#0 0x08067af1 in WidgetToWindow (w=0x852c0d8) at
>#1 0x0806bc91 in GetTopDocument (w=0x89) at window.c:4112
>#2 0x0806bcb7 in IsTopDocument (window=0x8514f28) at
>#3 0x08067c34 in UpdateWindowTitle (window=0x8514f28)
>#4 0x0805608c in CheckForChangesToFile
(window=0x8514f28) at file.c:1968
>#5 0x418ee699 in XtCallCallbacks () from
>#6 0x419226c7 in _XtMatchAtom () from
>#7 0x41922bfb in _XtMatchAtom () from
>#8 0x419231f3 in _XtTranslateEvent () from
>#9 0x418fb73b in XtDispatchEventToWidget () from
>#10 0x418fcc3e in _XtSendFocusEvent () from
>#11 0x41904fbf in _XtHandleFocus () from
>#12 0x418fb76f in XtDispatchEventToWidget () from
>#13 0x418fc11d in _XtOnGrabList () from
>#14 0x418fc43f in XtDispatchEvent () from
>#15 0x080b897e in ServerDispatchEvent
(event=0x419306b0) at server.c:212
>#16 0x080b8884 in ServerMainLoop (context=0x83a4868)
>#17 0x0805178b in main (argc=2, argv=0xbffff6e4) at
>It was busy removing some directories where NEdit had
>documents, and closed two of them. A second late I
look back and NEdit
>was frozen solid with all of the CPU it could get. Now
CPU usage is
>back to normal, but NEdit is still frozen.
I'm guessing that the following has happened (in this
- You deleted a file.
- You closed the matching window.
- A focus change event arrived late (asynchronously)
of the widgets were destroyed already.
- The CheckForChangesToFile callback is unaware of
destructions and (indirectly) calls WidgetToWindow.
- WidgetToWindow tries to climb the widget hierarchy
the top widget, but because some of the structures have
been destroyed it accesses garbage and it ends up in an
endless loop. It could have crashed equally well.
I've seen similar things before, but they are almost
reproduce (timing is crucial). Most probably, it's our
fault, and not a
bug in X, but I have no idea what is wrong exactly or
how you could
safely detect/avoid accesses to destroyed widgets.