emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs crashs when remote x-windows closes after make-frame-on-displa


From: Jan Djärv
Subject: Re: emacs crashs when remote x-windows closes after make-frame-on-display even when other frame was closed due to assertion in xcd_xlib.c (!c->xlib.lock)
Date: Fri, 04 Jan 2008 09:14:01 +0100
User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031)

Thanks for the backtrace.

This is a bug in xcb. Granted the XSync call is not needed and can be avoided. But that doesn't help. Emacs uses Xt/Gtk+ and Emacs must call functions in those toolkits to close the display and clean up data. Otherwise there will be a memory leak. Those functions will call Xlib functions also. Xcb must allow this. Most applications just exit when they get an I/O error, but Emacs can have several display conections and shall not exit just because one of them is closed.

The Xlib calls below is all done from the same thread so what is the lock protecting anyway?

I suggest filing a bug report to Xcb. This is a change in behaviour from classic Xlib.

        Jan D.


Matan Ninio skrev:
emacs: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.

Program received signal SIGABRT, Aborted.
0xb7a547d6 in raise () from /lib/libc.so.6
(gdb) backtrace
#0  0xb7a547d6 in raise () from /lib/libc.so.6
#1  0xb7a560f1 in abort () from /lib/libc.so.6
#2  0xb7a4db50 in __assert_fail () from /lib/libc.so.6
#3  0xb7a256f4 in xcb_xlib_lock () from /usr/lib/libxcb-xlib.so.0
#4  0xb7cbc6cc in _XCBInitDisplayLock () from /usr/lib/libX11.so.6
#5  0xb7cb12f5 in XSync () from /usr/lib/libX11.so.6
#6  0x080c58e9 in x_catch_errors (dpy=0x8a25f40) at xterm.c:7572
#7  0x080c7187 in x_connection_closed (dpy=0x8a25f40,
error_message=0xbfac7550 "Connection lost to X server `:1.0'") at
xterm.c:7726
#8  0x080c747b in x_io_error_quitter (display=0x8a25f40) at xterm.c:7888
#9  0xb7cb59dd in _XIOError () from /usr/lib/libX11.so.6
#10 0xb7cbd1ba in _XReadPad () from /usr/lib/libX11.so.6
#11 0xb7cbd918 in _XEventsQueued () from /usr/lib/libX11.so.6
#12 0xb7ca69a3 in XPending () from /usr/lib/libX11.so.6
#13 0x080cb141 in XTread_socket (sd=0, expected=1, hold_quit=0xbfac8a70) at
xterm.c:7070
#14 0x080f3b50 in read_avail_input (expected=1) at keyboard.c:6843
#15 0x080f3d9a in handle_async_input () at keyboard.c:6989
#16 0x080f3f51 in input_available_signal (signo=29) at keyboard.c:7031
#17 <signal handler called>
#18 0xb7af5ff8 in ___newselect_nocancel () from /lib/libc.so.6
#19 0x08181f55 in select_wrapper (n=1, rfd=0x0, wfd=0xbfac8ff8, xfd=0x0,
tmo=0xbfac9128) at process.c:4225
#20 0x08184e23 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=137472201, wait_proc=0x0,
just_wait_proc=0) at process.c:4594
#21 0x08053fe6 in sit_for (timeout=240, reading=1, do_display=1) at
dispnew.c:6579
#22 0x080f8fdb in read_char (commandflag=1, nmaps=2, maps=0xbfac93f0,
prev_event=137472201, used_mouse_menu=0xbfac9488, end_time=0x0) at
keyboard.c:2904
#23 0x080fabe5 in read_key_sequence (keybuf=0xbfac9534, bufsize=30,
prompt=137472201, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9135
#24 0x080fc6f3 in command_loop_1 () at keyboard.c:1618
#25 0x08152e20 in internal_condition_case (bfun=0x80fc560 <command_loop_1>,
handlers=137517657, hfun=0x80f7020 <cmd_error>) at eval.c:1481
#26 0x080f6473 in command_loop_2 () at keyboard.c:1329
#27 0x08152efa in internal_catch (tag=137510841, func=0x80f6450
<command_loop_2>, arg=137472201) at eval.c:1222
#28 0x080f6e5c in command_loop () at keyboard.c:1308
#29 0x080f71fa in recursive_edit_1 () at keyboard.c:1006
#30 0x080f72e6 in Frecursive_edit () at keyboard.c:1067
#31 0x080ed160 in main (argc=3, argv=0xbfac9bb4) at emacs.c:1762
(gdb)
Jan Djärv wrote:

Can you put a break at the assertion position and get a backtrace when the assertion is hit?

        Jan D.

Richard Stallman skrev:
Would someone please fix this, then ack?

To: address@hidden
From: Matan Ninio <address@hidden>
Date: Mon, 15 Oct 2007 09:10:05 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: emacs crashs when remote x-windows closes after
        make-frame-on-display even when other frame was closed due to
assertion in xcd_xlib.c (!c->xlib.lock)

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

open emacs in X, make frame on display to some other display (either
directly or via ssh -X -Y) with "make-frame-on-display".  Close the
other frame.  all still OK.  close the other display (logout, kill X or
kill ssh link), and emacs will crash with:
  emacs: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.

Similar problems happened with other applications when the system moved
from xlib to xcb-xlib.  This is probably due to strict checking of
actions that had been left unchecked in past versions of the library,
and therefor should be considered an Emacs bug rather then a library
bug.
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/22.1/etc/DEBUG for instructions.


In GNU Emacs 22.1.1 (i486-pc-linux-gnu, GTK+ Version 2.10.13)
 of 2007-08-22 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version
11.0.10300000
configured using `configure  '--build=i486-linux-gnu'
'--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs22:/etc/emacs:/usr/local/share/emacs/22.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.1/leim'
'--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN
-g -O2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  icomplete-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
M-x r e p o r t SPC b <backspace> e m <tab> <retur
n>

Recent messages:
Loading monk-fn-handler...done
Loading desktop...done
Loading edmacro...done
`pmwiki-multi-source': mmm-mode is not installed
Loading semantic-el...done
Customized for CSE-HUJI
Loading shell...done
Customized for CSE-HUJI
Loading ansi-color...done
Loading emacsbug...done


_______________________________________________
Emacs-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-devel







reply via email to

[Prev in Thread] Current Thread [Next in Thread]