Re: Emacs crash in X

[Satyaki Das]

Richard Stallman <address@hidden> writes:

> I use Sawfish; does it have any analogous feature?
> If so, can someone tell me how to do this with Sawfish?

I don't have sawfish installed on my current machine. I used
to have it on a previous machine that has since died. There is
a program called sawfish-ui (which is a GUI config utility).
That has an option to choose workspaces instead of viewports.

> You can also debug this yourself.  Run Emacs under GDB then
> evaluate (x-synchronize t), then make it fail.

If I evaluate (x-synchronize t) then emacs doesn't die any
more.

>                                                 That way you
> will get a useful backtrace.  Please read etc/DEBUG for more
> suggestions for how to debug this.

So I read etc/DEBUG and followed the recommendations there.
First I simplified the test program to:

(progn
  (setq focus-follows-mouse nil)
  (x-focus-frame (window-frame (get-buffer-window "*scratch*" t))))

Then I set a break point on Fx_focus_frame. Then I started
emacs (with -q --no-site-file) from inside gdb and did the
following:

1. C-x 5 2 to create new frame.

2. Move new frame to a different workspace and switch back to
   the original workspace.

3. Load the file containing the test program in the frame in
   the current workspace with C-x C-f ~/pp.el
   The file pp.el contains:
     (progn
       (setq focus-follows-mouse nil)
       (x-focus-frame (window-frame (get-buffer-window "*scratch*" t))))

4. Go to the end of the file and evaluate the expression with:
       M-> C-x C-e
   [When evaluating the expression the setup needed is that
    there should be two frames one showing *scratch* and the
    other showing pp.el and they are be in separate
    workspaces.]

5. The break point in Fx_focus_frame is hit. Now I use next to
   step through, evaluating:
     call XSync (f->output_data.x->display_info->display, 0)
   whenever I am about to execute XSetInputFocus statement.
   Here I tried three different things:
     1. call XSync ... before and after the XSetInputFocus
        statement as etc/DEBUG says to do. This doesn't make
        emacs to die.
     2. call XSync ... after the XSetInputFocus statement.
        Emacs doesn't die here either.
     3. call Xsync before the XSetInputFocus. Emacs goes into
        x_error_quitter.

6. The backtrace for case 3 above is as follows:

   #0  x_error_quitter (display=0xbffd13d4, error=0x402b8b28) at xterm.c:12415
   #1  0x080b7fc2 in x_error_handler (display=0x84e17f0, error=0xbffd12e4)
       at xterm.c:12433
   #2  0x40211831 in _XError () from /usr/X11R6/lib/libX11.so.6
   #3  0x4020fdcf in _XReply () from /usr/X11R6/lib/libX11.so.6
   #4  0x401fcf1c in XInternAtom () from /usr/X11R6/lib/libX11.so.6
   #5  0x4053edd1 in _XimExtension ()
      from /usr/X11R6/lib/X11/locale/common/ximcp.so.2
   #6  0x4022b845 in XFilterEvent () from /usr/X11R6/lib/libX11.so.6
   #7  0x080b52c1 in XTread_socket (sd=0, bufp=0xbffd2a94, numchars=4096, 
       expected=1) at xterm.c:10210
   #8  0x080dd770 in read_avail_input (expected=1) at keyboard.c:6462
   #9  0x080dd926 in input_available_signal (signo=29) at keyboard.c:6615
   #10 <signal handler called>
   #11 0x42028cc1 in kill () from /lib/i686/libc.so.6
   #12 0x080dd952 in reinvoke_input_signal () at keyboard.c:6644
   #13 0x080c3a05 in Fx_focus_frame (frame=1213197936) at xfns.c:4720
   #14 0x0812eb52 in Feval (form=135835064) at eval.c:2097
   #15 0x0812c661 in Fprogn (args=0) at eval.c:425
   #16 0x0812eca4 in Feval (form=1210509112) at eval.c:2044
   #17 0x0812f506 in Ffuncall (nargs=2, args=0xbffff014) at eval.c:2742
   #18 0x0815707c in Fbyte_code (bytestr=407579124, vector=1, 
       maxdepth=-1073745904) at bytecode.c:709
   #19 0x0812f7f7 in funcall_lambda (fun=1210349712, nargs=1, 
       arg_vector=0xbffff144) at eval.c:2929
   #20 0x0812f3df in Ffuncall (nargs=2, args=0xbffff140) at eval.c:2799
   #21 0x0815707c in Fbyte_code (bytestr=407579100, vector=1, 
       maxdepth=-1073745600) at bytecode.c:709
   #22 0x0812f7f7 in funcall_lambda (fun=1210350268, nargs=1, 
       arg_vector=0xbffff284) at eval.c:2929
   #23 0x0812f3df in Ffuncall (nargs=2, args=0xbffff280) at eval.c:2799
   #24 0x0812b201 in Fcall_interactively (function=405469220, 
       record_flag=405469220, keys=1210835384) at callint.c:819
   #25 0x080e16a2 in Fcommand_execute (cmd=405554668, record_flag=405469220, 
       keys=405469220, special=405469220) at keyboard.c:9536
   #26 0x080d6fb2 in command_loop_1 () at keyboard.c:1690
   #27 0x0812d9ee in internal_condition_case (bfun=0x80d6c88 <command_loop_1>, 
       handlers=405565828, hfun=0x80d6884 <cmd_error>) at eval.c:1353
   #28 0x080d6b6e in command_loop_2 () at keyboard.c:1274
   #29 0x0812d591 in internal_catch (tag=0, func=0x80d6b50 <command_loop_2>, 
       arg=405469220) at eval.c:1114
   #30 0x080d6b24 in command_loop () at keyboard.c:1253
   #31 0x080d6663 in recursive_edit_1 () at keyboard.c:969
   #32 0x080d6770 in Frecursive_edit () at keyboard.c:1025
   #33 0x080d50cb in main (argc=3, argv=0xbffffa44) at emacs.c:1659
   #34 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

So it seems that adding a XSync after the call to
XSetInputFocus avoids the problem. I have verified that by
recompiling after making this change.

Satyaki