all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mike Mattie <codermattie@gmail.com>
To: emacs-devel@gnu.org
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, 4 Jan 2008 18:27:44 -0800	[thread overview]
Message-ID: <20080104182744.2a2f449c@reforged> (raw)
In-Reply-To: <477DEAC9.5020005@swipnet.se>


[-- 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

  reply	other threads:[~2008-01-05  2:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-10-15  7:10 Matan Ninio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080104182744.2a2f449c@reforged \
    --to=codermattie@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.