================================================================ Dear Bug Team! I've noticing occasional deadlocks between XEmacs and the X server. Every time I can remember it happending I've had gdb-mode running in a buffer (though I'm usually not actively accessing that buffer). It may be correlated with starting a second frame on that same process. An strace of the running process shows it hanging on a select of the unix socket that corresponds to the X server. I've found this: http://list-archive.xemacs.org/xemacs-patches/200212/msg00029.html which seems related, but as you can tell by the data below I'm running 21.4.12 (which supposedly has things much better than before). I'm very interested in having this problem fixed, but if there's a workaround to break the deadlock, I'd love to hear about that, too. Also, if there's reason to believe that 21.5.x is less prone to this bug, I'd considering using that branch. Finally, if you have instructions on how better to reproduce the old bug, I'm happy to work with you to investigate further. Thanks! Greg ================================================================ System Info to help track down your bug: --------------------------------------- uname -a: Linux porky.devel.redhat.com 2.4.20-2.48bigmem #1 SMP Thu Feb 13 11:31:10 EST 2003 i686 i686 i386 GNU/Linux ./configure 'i386-redhat-linux-gnu' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--datadir=/usr/share' '--libdir=/usr/lib' '--mandir=/usr/share/man/man1' '--infodir=/usr/share/info' '--with-gpm=no' '--with-sound=native' '--with-pop' '--mail-locking=lockf' '--with-clash-detection' '--debug=no' '--error-checking=none' '--with-mule=yes' '--with-database=berkdb' '--with-ldap=yes' '--with-hesiod=no' '--with-canna=yes' '--with-wnn=yes' '--with-widgets=motif' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=motif' '--with-xim=xlib' '--with-msw=no' '--with-xfs=yes' '--pdump' XEmacs 21.4.12 "Portable Code" configured for `i386-redhat-linux'. Compilation / Installation: Source code location: /usr/src/build/225655-i386/BUILD/xemacs-21.4.12 Installation prefix: /usr Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -O2 -march=i386 -mcpu=i686 -g Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. - Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Mail: Compiling in support for POP mail retrieval. Compiling in support for "lockf" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Using the new portable dumper. Load-Path Lisp Shadows: ---------------------- (/usr/share/xemacs/xemacs-packages/lisp/apel/timezone /usr/share/xemacs/xemacs-packages/lisp/xemacs-base/timezone /usr/share/xemacs/xemacs-packages/lisp/build/build-report /usr/share/xemacs-21.4.12/lisp/build-report /usr/share/xemacs/xemacs-packages/lisp/apel/alist /usr/share/xemacs-21.4.12/lisp/alist) Installed XEmacs Packages: ------------------------- ((zenirc :version 1.13 :type regular) (xslt-process :version 1.11 :type regular) (xslide :version 1.04 :type regular) (xemacs-devel :version 1.5 :type single-file) (xemacs-base :version 1.75 :type regular) (w3 :version 1.28 :type regular) (vm :version 7.07 :type regular) (viper :version 1.35 :type regular) (view-process :version 1.12 :type regular) (vhdl :version 1.16 :type regular) (vc-cc :version 1.21 :type regular) (vc :version 1.35 :type regular) (tramp :version 1.11 :type regular) (tpu :version 1.12 :type regular) (tooltalk :version 1.13 :type regular) (tm :version 1.35 :type regular) (time :version 1.12 :type regular) (textools :version 1.14 :type regular) (text-modes :version 1.58 :type single-file) (texinfo :version 1.23 :type regular) (supercite :version 1.19 :type regular) (strokes :version 1.08 :type regular) (speedbar :version 1.26 :type regular) (sounds-wav :version 1.1 :type regular) (sounds-au :version 1.1 :type regular) (sml-mode :version 0.07000000000000001 :type regular) (slider :version 1.13 :type regular) (sieve :version 1.11 :type regular) (sh-script :version 1.17 :type regular) (sgml :version 1.08 :type regular) (semantic :version 1.17 :type regular) (scheme :version 1.13 :type regular) (sasl :version 1.12 :type regular) (ruby-modes :version 1.01 :type regular) (rmail :version 1.13 :type regular) (reftex :version 1.28 :type regular) (python-modes :version 1.02 :type single-file) (psgml-dtds :version 1.02 :type regular) (psgml :version 1.38 :type regular) (ps-print :version 1.08 :type regular) (prog-modes :version 1 .72 :type single-file) (pgg :version 1.02 :type regular) (perl-modes :version 1.04 :type single-file) (pcomplete :version 1.02 :type regular) (pcl-cvs :version 1.64 :type regular) (pc :version 1.25 :type single-file) (os-utils :version 1.3 :type single-file) (ocaml :version 0.04 :type regular) (net-utils :version 1.31 :type single-file) (mmm-mode :version 1.0 :type regular) (misc-games :version 1.16 :type single-file) (mine :version 1.14 :type regular) (mh-e :version 1.17 :type regular) (mailcrypt :version 2.12 :type regular) (mail-lib :version 1.56 :type regular) (liece :version 1.1 :type regular) (jde :version 1.43 :type regular) (ispell :version 1.24 :type regular) (ilisp :version 1.29 :type regular) (igrep :version 1.1 :type regular) (idlwave :version 1.28 :type regular) (ibuffer :version 1.08 :type regular) (hm--html-menus :version 1.18 :type regular) (haskell-mode :version 1.05 :type regular) (gnus :version 1.65 :type regular) (gnats :version 1.15 :type regular) (games :version 1.13 :type regular) (fsf-compat :version 1.12 :type single-file) (frame-icon :version 1.09 :type regular) (fortran-modes :version 1.02 :type single-file) (forms :version 1.14 :type regular) (footnote :version 1.15 :type regular) (eudc :version 1.37 :type regular) (eterm :version 1.13 :type regular) (ess :version 1.03 :type regular) (eshell :version 1.04 :type regular) (emerge :version 1.09 :type regular) (elib :version 1.1 :type single-file) (eieio :version 1.04 :type regular) (efs :version 1.29 :type regular) (edt :version 1.12 :type regular) (edit-utils :version 1.98 :type single-file) (ediff :version 1.46 :type regular) (edebug :version 1.15 :type regular) (ecrypto :version 0.12 :type regular) (ecb :version 1.01 :type regular) (docbookide :version 0.06 :type regular) (dired :version 1.13 :type regular) (dictionary :version 1.11 :type regular) (debug :version 1.16 :type regular) (crisp :version 1.12 :type regular) (cookie :version 1.14 :type regular) (clearcase :version 1.04 :type regular) (cc-mode :version 1.32 :type regular) (calendar :version 1.19 :type regular) (calc :version 1.23 :type regular) (c-support :version 1.16 :type single-file) (build :version 1.1 :type regular) (bbdb :version 1.21 :type regular) (auctex :version 1.33 :type regular) (ada :version 1.13 :type regular) (mule-ucs :version 1.04 :type regular) (mule-base :version 1.42 :type regular) (lookup :version 1.13 :type regular) (locale :version 1.2 :type regular) (leim :version 1.2 :type regular) (latin-unity :version 1.07 :type regular) (egg-its :version 1.26 :type regular) (edict :version 1.13 :type regular)) Installed Modules: ----------------- Features: -------- (mail-abbrevs xemacsbug shadow sendmail rfc822 zenirc-autoloads xslt-process-autoloads xslide-autoloads xemacs-devel-autoloads xemacs-base-autoloads w3-autoloads vm-autoloads viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads tm-autoloads time-autoloads textools-autoloads text-modes-autoloads texinfo-autoloads supercite-autoloads strokes-autoloads speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads sml-mode-autoloads slider-autoloads sieve-autoloads sh-script-autoloads sgml-autoloads semantic-autoloads scheme-autoloads sasl-autoloads ruby-modes-autoloads rmail-autoloads reftex-autoloads python-modes-autoloads psgml-dtds-autoloads psgml-autoloads ps-print-autoloads prog-modes-autoloads pgg-autoloads perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads pc-autoloads os-utils-autoloads ocaml-autoloads net-utils-autoloads mmm-mode-autoloads misc-games-autoloads mine-autoloads mh-e-autoloads mailcrypt-autoloads mail-lib-autoloads liece-autoloads jde-autoloads ispell-autoloads ilisp-autoloads igrep-autoloads idlwave-autoloads ibuffer-autoloads hm--html-menus-autoloads haskell-mode-autoloads gnus-autoloads gnats-autoloads games-autoloads fsf-compat-autoloads frame-icon-autoloads fortran-modes-autoloads forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads ess-autoloads eshell-autoloads emerge-autoloads elib-autoloads eieio-autoloads efs-autoloads edt-autoloads edit-utils-autoloads ediff-autoloads edebug-autoloads ecrypto-autoloads ecb-autoloads docbookide-autoloads dired-autoloads dictionary-autoloads debug-autoloads crisp-autoloads cookie-autoloads clearcase-autoloads cc-mode-autoloads calendar-autoloads calc-autoloads c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads apel-autoloads ada-autoloads mule-ucs-autoloads mule-base-autoloads lookup-autoloads locale-autoloads leim-autoloads latin-unity-autoloads egg-its-autoloads edict-autoloads lisp-autoloads loadhist auto-show fontl-hooks x-iso8859-1 canna-leim slovenian czech romanian ccl mule-help code-cmds gutter-items menubar-items x-menubar mode-motion mouse itimer auto-save lisp-mode easymenu iso8859-1 page buff-menu lib-complete cus-file derived frame text-props obsolete cus-start custom widget cl-extra mini-cl cl cl-19 packages backquote very-early-lisp postgresqlv7 postgresql CANNA file-coding wnn mule lucid-scrollbars cut-buffer lucid-menubars motif-dialogs x c-balloon-help tty-frames tty toolbar native-sound scrollbar unix-processes multicast network-streams subprocesses modules menu-accelerator-support menubar berkeley-db md5 xemacs xim gutter tiff png gif jpeg xpm xbm lisp-float-type linux dialog devices window-system base64) Recent keystrokes: ----------------- M-x r e p o r t - x e TAB RET Recent messages (most recent first): ----------------------------------- Loading xemacsbug...done Loading xemacsbug... Loading /usr/share/xemacs/site-packages/lisp/site-start.d/psgml-init.el...done Loading /usr/share/xemacs/site-packages/lisp/site-start.d/psgml-init.el...

>>>>> "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.

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.

>>>> "Greg" == Greg Badros <greg(a)google.com&gt; writes:

Stephen J. Turnbull wrote: > Greg> #6 0x0819ff42 in x_atom_to_symbol (d=0x0, atom=3221218228) at select-x.c:191 > > Thanks for the stack traces. Something is very wrong here; `d' is > supposed to be a pointer to a XEmacs display description struct, and > seems to get dereferenced immediately on entry into x_atom_to_symbol. > > Why doesn't this crash?!? Not only that, but x_handle_selection_clear() obtains this value from get_device_from_display(), which calls abort() rather than return an NULL pointer. I'm not sure that the debug output can be trusted. -- Glynn Clements <glynn.clements(a)virgin.net&gt;

Note: the backtrace which Stephen queried *does* have _XRead() in it. Also, *all* of the backtraces have a NULL device argument, which is just too improbably (it not only shouldn't be able happen, but if it did, XEmacs should segfault almost instantly, before it gets down into Xlib).

> Sorry for the bad backtrace-- I'm pretty sure that I just pointed at > the wrong binary when I generated that one. I don't think so. The odd one out (the second one) appears to differ from the other two only in that there aren't any symbols for the Xlib portion. Most of the addresses match.

> Thanks very much, guys, for investigating this.... I'm hating the > thought of using GNU Emacs again, but I'm losing work regularly > because of these hangs (and so are other folks in the office). The thing is, everything points towards problems at a lower level than XEmacs itself, i.e. in the communication between Xlib and the X server (X Errors mentioning obviously bogus resource IDs, Xlib's "unexpected async reply" message, crashes in XRead()).

Assuming that neither the X server nor Xlib are outright broken, the next most likely explanations include Xlib not being compatible with other key components (e.g. libc, or the Xlib headers), or something dumping garbage into the socket.

This is just a complete shot in the dark, but can you check the output from "ls -l /proc/<pid>/fd", where <pid> is the PID of the XEmacs process. I'm curious as to whether the X socket is getting assigned to one of the standard descriptors (0, 1 or 2).