* 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)
@ 2007-10-18 20:08 Richard Stallman
2007-10-19 6:00 ` Jan Djärv
0 siblings, 1 reply; 5+ messages in thread
From: Richard Stallman @ 2007-10-18 20:08 UTC (permalink / raw)
To: emacs-devel
Would someone please fix this, then ack?
To: bug-gnu-emacs@gnu.org
From: Matan Ninio <emacs@cs.ng.ninio.org>
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 bug-gnu-emacs@gnu.org 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
--
Matan Ninio
-----------------------------------------
VI VI VI - The Roman Number of The Beast
^ permalink raw reply [flat|nested] 5+ messages in thread
* 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)
2007-10-18 20:08 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) Richard Stallman
@ 2007-10-19 6:00 ` Jan Djärv
2007-12-24 13:02 ` Matan Ninio
0 siblings, 1 reply; 5+ messages in thread
From: Jan Djärv @ 2007-10-19 6:00 UTC (permalink / raw)
To: emacs; +Cc: rms, emacs-devel
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: bug-gnu-emacs@gnu.org
> From: Matan Ninio <emacs@cs.ng.ninio.org>
> 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 bug-gnu-emacs@gnu.org 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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* 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)
2007-10-19 6:00 ` Jan Djärv
@ 2007-12-24 13:02 ` Matan Ninio
2008-01-04 8:14 ` Jan Djärv
0 siblings, 1 reply; 5+ messages in thread
From: Matan Ninio @ 2007-12-24 13:02 UTC (permalink / raw)
To: Emacs-devel
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: bug-gnu-emacs@gnu.org
>> From: Matan Ninio <emacs@cs.ng.ninio.org>
>> 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 bug-gnu-emacs@gnu.org 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
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
--
View this message in context: http://www.nabble.com/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-%28%21c-%3Exlib.lock%29-tp13282726p14487449.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 5+ messages in thread
* 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)
2007-12-24 13:02 ` Matan Ninio
@ 2008-01-04 8:14 ` Jan Djärv
2008-01-05 2:27 ` Mike Mattie
0 siblings, 1 reply; 5+ messages in thread
From: Jan Djärv @ 2008-01-04 8:14 UTC (permalink / raw)
To: Matan Ninio; +Cc: Emacs-devel
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: bug-gnu-emacs@gnu.org
>>> From: Matan Ninio <emacs@cs.ng.ninio.org>
>>> 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 bug-gnu-emacs@gnu.org 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
>> Emacs-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-devel
>>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* 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)
2008-01-04 8:14 ` Jan Djärv
@ 2008-01-05 2:27 ` Mike Mattie
0 siblings, 0 replies; 5+ messages in thread
From: Mike Mattie @ 2008-01-05 2:27 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 8627 bytes --]
On Fri, 04 Jan 2008 09:14:01 +0100
Jan Djärv <jan.h.d@swipnet.se> wrote:
> 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.
Many distros have already patched xcb to disable this. I think it has gone
upstream as well. It should disappear soon.
>
> 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: bug-gnu-emacs@gnu.org
> >>> From: Matan Ninio <emacs@cs.ng.ninio.org>
> >>> 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 bug-gnu-emacs@gnu.org
> >>> 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
> >> Emacs-devel@gnu.org
> >> http://lists.gnu.org/mailman/listinfo/emacs-devel
> >>
> >>
> >
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-01-05 2:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-18 20:08 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) Richard Stallman
2007-10-19 6:00 ` Jan Djärv
2007-12-24 13:02 ` Matan Ninio
2008-01-04 8:14 ` Jan Djärv
2008-01-05 2:27 ` Mike Mattie
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).