Re: [Bug: 21.4.12] Deadlock with X?

Hi Stephen, Here's another backtrace of XEmacs deadlocked. Thanks, Greg (gdb) bt #0 0xffffe002 in ?? () #1 0x420276f8 in ?? () #2 0x403b3a07 in ?? () #3 0x403b454d in ?? () #4 0x403a1722 in ?? () #5 0x0819fd99 in symbol_to_x_atom (d=0x0, sym=-1073753276, only_if_exists=0) at select-x.c:147 #6 0x0819efe7 in lisp_data_to_selection_data (d=0x83d3618, obj=158636024, data_ret=0xbfffd958, type_ret=0xbfffd344, size_ret=0xbfffd960, format_ret=0xbfffd964) at select-x.c:1380 #7 0x0819eb39 in x_handle_selection_request (event=0x870d5fc) at select-x.c:639 #8 0x0818e251 in emacs_Xt_handle_magic_event (emacs_event=0xbfffd344) at event-Xt.c:1894 #9 0x080d950a in execute_internal_event (event=141612520) at event-stream.c:515 #10 0x080d9fc5 in Fdispatch_event (event=141612520) 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=0xbfffdeb4, envp=0xbfffdebc, restart=0) at emacs.c:2460 #17 0x080ab58d in main (argc=0, argv=0x0, envp=0x0) at emacs.c:2892 #18 0x420156a4 in ?? () Greg Badros <greg(a)google.com&gt; writes: > 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.