Re: [Bug: 21.4.12] Deadlock with X?

>>>>> "Greg" == Greg Badros <greg(a)google.com&gt; writes: Greg> Every time I can remember it happending I've had gdb-mode Greg> running in a buffer (though I'm usually not actively Greg> accessing that buffer). It may be correlated with starting Greg> a second frame on that same process. gdb-mode is pretty evil stuff; it runs timers and checks the buffer rather than parsing the text as it is added. I don't know if this is necessary anymore, and I doubt that code has been updated in many years. Greg> An strace of the running process shows it hanging on a Greg> select of the unix socket that corresponds to the X server. Can you get us a stack trace while it's hung? Greg> I'm very interested in having this problem fixed, but if Greg> there's a workaround to break the deadlock, I'd love to hear Greg> about that, too. ISTR that there were ways to get XEmacs to wake up out of some deadlocks. Unfortunately, I can't find the comment/documentation at the moment. If this is caused by X, maybe moving the mouse and/or kill -SIGIO might help, per the following comment from event-Xt.c: /* #### I'm struggling to understand how the X event loop really works. Here is the problem: When widgets get mapped / changed etc the actual display updates are done asynchronously via X events being processed - this normally happens when XtAppProcessEvent() gets called. However, if we are executing lisp code or even doing redisplay we won't necessarily process X events for a very long time. This has the effect of widgets only getting updated when XEmacs only goes into idle, or some other event causes processing of the X event queue. XtAppProcessEvent can get called from the following places: emacs_Xt_next_event () - this is normal event processing, almost any non-X event will take precedence and this means that we cannot rely on it to do the right thing at the right time for widget display. drain_X_queue () - this happens when SIGIO gets tripped, processing the event queue allows C-g to be checked for. It gets called from emacs_Xt_event_pending_p (). In order to solve this I have tried introducing a list primitive - dispatch-non-command-events - which forces processing of X events related to display. Unfortunately this has a number of problems, one is that it is possible for event_stream_event_pending_p to block for ever if there isn't actually an event. I guess this can happen if we drop the synthetic event for reason. It also relies on SIGIO processing which makes things rather fragile. People have seen behaviour whereby XEmacs blocks until you move the mouse. This seems to indicate that dispatch-non-command-events is blocking. It may be that in a SIGIO world forcing SIGIO processing does the wrong thing. */ -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.