Re: [Bug: 21.4.12] Deadlock with X?

Sorry it took a while to get back to you -- I rebuilt with -g and --debug and here's a stack trace when it's hung. BTW, it's now clear to me that it's *not* related to gdb or comint or any other inferior-process mode. The hanging does seem to occur more frequently when there are background processes and when the XEmacs is running remotely (but it has happened when running locally w/ a relatively unloaded machine). I've kept the core, so let me know if there's more that you want... Thanks, Greg #0 0xffffe002 in ?? () #1 <signal handler called> #2 0xffffe002 in ?? () #3 0x403b3a07 in _XRead () from /usr/X11R6/lib/libX11.so.6 #4 0x403b454d in _XReply () from /usr/X11R6/lib/libX11.so.6 #5 0x4039bc07 in XGetAtomName () from /usr/X11R6/lib/libX11.so.6 #6 0x0819ff42 in x_atom_to_symbol (d=0x0, atom=3221218228) at select-x.c:191 #7 0x0819f741 in x_handle_selection_clear (event=0x8bab6ac) at select-x.c:684 #8 0x0818e39f in emacs_Xt_handle_magic_event (emacs_event=0xbfffe3b4) at event-Xt.c:1898 #9 0x080d950a in execute_internal_event (event=146454168) at event-stream.c:515 #10 0x080d9fc5 in Fdispatch_event (event=146454168) at event-stream.c:4263 #11 0x080947bf in Fcommand_loop_1 () at cmdloop.c:583 #12 0x080ad4e7 in condition_case_1 (handlers=1082309400, bfun=0x8094a58 <command_loop_1>, barg=1082309760, hfun=0x8094a70 <cmd_error>, harg=1082309760) at eval.c:1652 #13 0x08094c3c in command_loop_2 (dummy=1082309760) at cmdloop.c:256 #14 0x080ad3c1 in internal_catch (tag=0, func=0x8094bfc <command_loop_2>, arg=1082309760, threw=0x0) at eval.c:1318 #15 0x080944f0 in initial_command_loop (load_me=0) at cmdloop.c:305 #16 0x080aabdd in xemacs_21_4_12_i686_pc_linux (argc=1, argv=0xbfffedb4, envp=0xbfffedbc, restart=0) at emacs.c:2460 #17 0x080ab58d in main (argc=0, argv=0x0, envp=0x0) at emacs.c:2892 #18 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: > >>>>> "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.