bjoyce@coherent.com (Bob Joyce) (11/16/89)
Previous net messages led me to believe that XtDispatchEvent() was basically
re-entrant in X11R3. You merely had to avoid leaving XtDispatchEvent() by
a non-local goto. For instance, you couldn't safely call longjmp() from
within an embedded XtDispatchEvent(). Unfortunately, this is not sufficient.
To demonstrate the problem, call XtDestroyWidget() on a widget w while in a
callback, then enter a recursive event-processing loop. While in the
event-processing loop, call XtDestroyWidget() on w's parent. The procedure
ObjectDestroy(), which frees widget memory allocated, will be called twice on
w. On the second call, ObjectDestroy() accesses already freed memory.
Why are there two calls to ObjectDestroy()? Since the first call to
XtDestroyWidget() is from a callback, _XtSafeToDestroy is FALSE, and
XtDestroyWidget() queues up an XtPhase2Destroy on the _XtDestroyList rather
than destroying the widget immediately. Then, the second event loop is
entered. While in it, w's parent is destroyed, causing w to be destroyed
also. Then, our callback returns to the first event loop, at which point the
pending destroy for w is executed. Oops!
As it turns out, the two calls to ObjectDestroy() occur fairly close in time
to one another. So, you can usually get away with it. But every once in
a long while, a segmentation violation results.
Its not feasible to work-around the problem by avoiding calls to
XtDestroyWidget(). The calls may happen behind the scenes. For example, a
viewport widget might create and then destroy a scrollbar widget during the
process of widget management or realization. This is what happened in our
case.
To "work-around" the problem, we had to execute ugly hacks on both
XtDispatchEvent() and Recursive(). The idea was to keep track of all
widgets currently awaiting destruction (from outer event loops) and ensure
that Recursive() did not delete them in an interior loop.
A short Xaw-based program that illustrates the problem is available. Also
available is the hack used to work-around it. Contact me if interested.
I'll submit both to xbugs.
Xt people - do you agree this is a problem? If so, will it be fixed in R4?
Bob Joyce Coherent Thought Inc, 3350 W. Bayshore Rd #205, Palo Alto, CA 94303
UUCP: ...!{ames,sun,uunet}!coherent!bjoyce Domain: bjoyce@coherent.com
Internet: coherent!bjoyce@ames.arpa or ...@sun.com or ...uunet.uu.net
Phone: (415) 493-8805 Fax: (415) 493-1555swick@ATHENA.MIT.EDU (Ralph R. Swick) (11/16/89)
> Xt people - do you agree this is a problem? If so, will it be fixed in R4?
Yes, and we hope so. I thought up a while back a few other
scenarios in addition to the one you give under which the R3
implementation will fail, so it's definitely a known issue.