GNU bug report logs - #16676
24.3.50; Repeated but random hang

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16676 in the body.
You can then email your comments to 16676 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Repeated but random hang
Date: Thu, 06 Feb 2014 16:53:28 -0800

This has happened to me a handful of times now.  I'm reading news, and
then Emacs will suddenly halt.

Connecting to Emacs with gdb gives me the backtrace below.  Emacs will
consume 100% CPU at this point.

I've got the Emacs connected to gdb if anybody wants me to output some
data values...

#0  0x0000003f4de29e3c in XIfEvent () from /lib64/libX11.so.6
#1  0x0000003f4de706e4 in _XimXRead () from /lib64/libX11.so.6
#2  0x0000003f4de71330 in _XimReadData () from /lib64/libX11.so.6
#3  0x0000003f4de71621 in _XimRead () from /lib64/libX11.so.6
#4  0x0000003f4de5fa58 in _XimProtoDestroyIC () from /lib64/libX11.so.6
#5  0x0000003f4de4e042 in XDestroyIC () from /lib64/libX11.so.6
#6  0x00000000004c58cc in free_frame_xic (f=f <at> entry=0x3844808) at xfns.c:2041
#7  0x00000000004bd34c in x_free_frame_resources (f=0x3844808) at xterm.c:9201
#8  0x00000000004bd67b in x_destroy_window (f=<optimized out>) at xterm.c:9293
#9  0x0000000000422fda in delete_frame (frame=<optimized out>, force=12207810)
    at frame.c:1378
#10 0x00000000004b4450 in x_connection_closed (dpy=dpy <at> entry=0x1378070, 
    error_message=<optimized out>, 
    error_message <at> entry=0x7fffbe39c450 "Connection lost to X server `:0'")
    at xterm.c:7569
#11 0x00000000004b44fc in x_io_error_quitter (display=0x1378070)
    at xterm.c:7696
#12 0x0000003f4de43cce in _XIOError () from /lib64/libX11.so.6
#13 0x0000003f4de417ba in _XReadEvents () from /lib64/libX11.so.6
#14 0x0000003f4de29e51 in XIfEvent () from /lib64/libX11.so.6
#15 0x0000003f4de706e4 in _XimXRead () from /lib64/libX11.so.6
#16 0x0000003f4de71330 in _XimReadData () from /lib64/libX11.so.6
#17 0x0000003f4de71621 in _XimRead () from /lib64/libX11.so.6
#18 0x0000003f4de600d6 in _XimProtoSetICValues () from /lib64/libX11.so.6
#19 0x0000003f4de4e2ad in XSetICValues () from /lib64/libX11.so.6
#20 0x00000000004c59b3 in xic_set_preeditarea (w=w <at> entry=0x479df28, 
    x=x <at> entry=55, y=y <at> entry=528) at xfns.c:2061
#21 0x00000000004b4ce5 in x_draw_window_cursor (w=0x479df28, 
    glyph_row=<optimized out>, x=55, y=528, cursor_type=<optimized out>, 
    cursor_width=<optimized out>, on_p=<optimized out>, 
    active_p=<optimized out>) at xterm.c:7265
#22 0x0000000000454fd3 in display_and_set_cursor (w=w <at> entry=0x479df28, 
    on=on <at> entry=true, hpos=5, vpos=24, x=55, y=528) at xdisp.c:26983
#23 0x00000000004b3a4c in x_update_window_end (w=0x479df28, 
    cursor_on_p=<optimized out>, mouse_face_overwritten_p=<optimized out>)
    at xterm.c:546
#24 0x000000000041b1cd in update_window (w=w <at> entry=0x479df28, 
    force_p=<optimized out>, force_p <at> entry=true) at dispnew.c:3486
#25 0x000000000041c49b in update_window_tree (w=w <at> entry=0x479df28, 
    force_p=force_p <at> entry=true) at dispnew.c:3161
#26 0x000000000041e8fd in update_frame (f=f <at> entry=0x3844808, 
    force_p=<optimized out>, force_p <at> entry=false, 
    inhibit_hairy_id_p=inhibit_hairy_id_p <at> entry=false) at dispnew.c:3059
#27 0x000000000044b39d in redisplay_internal () at xdisp.c:13728
#28 0x000000000044c3f5 in redisplay () at xdisp.c:12911
#29 0x00000000004e34c1 in read_char (commandflag=1, map=map <at> entry=244463206,
    prev_event=12030258, 
    used_mouse_menu=used_mouse_menu <at> entry=0x7fffbe39f0ab, 
    end_time=end_time <at> entry=0x0) at keyboard.c:2563
#30 0x00000000004e4e23 in read_key_sequence (
    keybuf=keybuf <at> entry=0x7fffbe39f180, prompt=12030258, 
    dont_downcase_last=dont_downcase_last <at> entry=false, 
    can_return_switch_frame=can_return_switch_frame <at> entry=true, 
    fix_current_buffer=fix_current_buffer <at> entry=true, 
    prevent_redisplay=prevent_redisplay <at> entry=false, bufsize=30)
    at keyboard.c:9071
#31 0x00000000004e6a40 in command_loop_1 () at keyboard.c:1445
#32 0x0000000000546f6e in internal_condition_case (
    bfun=bfun <at> entry=0x4e6850 <command_loop_1>, handlers=<optimized out>, 
    hfun=hfun <at> entry=0x4dd920 <cmd_error>) at eval.c:1345
#33 0x00000000004d90de in command_loop_2 (ignore=ignore <at> entry=12030258)
    at keyboard.c:1170
#34 0x0000000000546e7b in internal_catch (tag=12077618, 
    func=func <at> entry=0x4d90c0 <command_loop_2>, arg=12030258) at eval.c:1109
#35 0x00000000004dd547 in command_loop () at keyboard.c:1149
#36 recursive_edit_1 () at keyboard.c:777
#37 0x00000000004dd832 in Frecursive_edit () at keyboard.c:841
#38 0x0000000000415cb5 in main (argc=<optimized out>, argv=0x7fffbe39f4d8)
    at emacs.c:1643




In GNU Emacs 24.3.50.9 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8)
 of 2014-01-31 on building.gnus.org
Repository revision: 116225 larsi <at> gnus.org-20140131210813-a5izp5d716k2jwv5
Windowing system distributor `Fedora Project', version 11.0.11404000
Important settings:
  value of $LANG: en_GB.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t

Recent input:
<help-echo> M-x r e p o r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util emacsbug message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils package ido flyspell ispell dired cl-macs
gv add-log mail-extr jka-compr cl cl-loaddefs cl-lib time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #8 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Fri, 07 Feb 2014 09:39:20 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 06 Feb 2014 16:53:28 -0800
> 
> This has happened to me a handful of times now.  I'm reading news, and
> then Emacs will suddenly halt.
> 
> Connecting to Emacs with gdb gives me the backtrace below.  Emacs will
> consume 100% CPU at this point.

Doesn't the following part of the backtrace (in particular, frame #10)
explain what happened?

> #9  0x0000000000422fda in delete_frame (frame=<optimized out>, force=12207810)
>     at frame.c:1378
> #10 0x00000000004b4450 in x_connection_closed (dpy=dpy <at> entry=0x1378070, 
>     error_message=<optimized out>, 
>     error_message <at> entry=0x7fffbe39c450 "Connection lost to X server `:0'")
>     at xterm.c:7569
> #11 0x00000000004b44fc in x_io_error_quitter (display=0x1378070)
>     at xterm.c:7696
> #12 0x0000003f4de43cce in _XIOError () from /lib64/libX11.so.6
> #13 0x0000003f4de417ba in _XReadEvents () from /lib64/libX11.so.6
> #14 0x0000003f4de29e51 in XIfEvent () from /lib64/libX11.so.6
> #15 0x0000003f4de706e4 in _XimXRead () from /lib64/libX11.so.6
> #16 0x0000003f4de71330 in _XimReadData () from /lib64/libX11.so.6
> #17 0x0000003f4de71621 in _XimRead () from /lib64/libX11.so.6
> #18 0x0000003f4de600d6 in _XimProtoSetICValues () from /lib64/libX11.so.6
> #19 0x0000003f4de4e2ad in XSetICValues () from /lib64/libX11.so.6
> #20 0x00000000004c59b3 in xic_set_preeditarea (w=w <at> entry=0x479df28, 
>     x=x <at> entry=55, y=y <at> entry=528) at xfns.c:2061
> #21 0x00000000004b4ce5 in x_draw_window_cursor (w=0x479df28, 
>     glyph_row=<optimized out>, x=55, y=528, cursor_type=<optimized out>, 
>     cursor_width=<optimized out>, on_p=<optimized out>, 
>     active_p=<optimized out>) at xterm.c:7265
> #22 0x0000000000454fd3 in display_and_set_cursor (w=w <at> entry=0x479df28, 
>     on=on <at> entry=true, hpos=5, vpos=24, x=55, y=528) at xdisp.c:26983

My reading of this is: Emacs was at the end of a redisplay cycle, when
a call to an X function signaled an error because "Connection lost to
X server `:0'".  Then Emacs tried to delete the frame on that display,
which again involves calls to X.

Do you know why the connection was lost in the first place?

Or is the complaint that when the connection is lost, Emacs hangs?

Message #11 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Fri, 07 Feb 2014 12:27:10 +0400

On 02/07/2014 11:39 AM, Eli Zaretskii wrote:

> My reading of this is: Emacs was at the end of a redisplay cycle, when
> a call to an X function signaled an error because "Connection lost to
> X server `:0'".  Then Emacs tried to delete the frame on that display,
> which again involves calls to X.

Yes, and I'm just curious why fatal X errors are handled in the same way
as non-fatal (by x_connection_closed). IIUC if X connection is broken
at the socket level, X protocol command may result in undefined behavior.
Manual says that XIfEvent flushes an event queue and waits for an event
matching the predicate; I don't know how the socket connection was broken
exactly, but it was "broken enough" to wait forever.

> Do you know why the connection was lost in the first place?

Shouldn't we try to check errno x_io_error_quitter? Socket-related calls
should set it in case of error.

Dmitry

Message #14 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Fri, 07 Feb 2014 17:08:00 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> My reading of this is: Emacs was at the end of a redisplay cycle, when
> a call to an X function signaled an error because "Connection lost to
> X server `:0'".  Then Emacs tried to delete the frame on that display,
> which again involves calls to X.
>
> Do you know why the connection was lost in the first place?

As far as I can tell, no X connection was lost.  That is, the frame is
still there, and I'm not trying to kill and frames or anything.  This is
in the middle of reading a Gnus group.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #17 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Sat, 08 Feb 2014 10:48:35 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16676 <at> debbugs.gnu.org
> Date: Fri, 07 Feb 2014 17:08:00 -0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > My reading of this is: Emacs was at the end of a redisplay cycle, when
> > a call to an X function signaled an error because "Connection lost to
> > X server `:0'".  Then Emacs tried to delete the frame on that display,
> > which again involves calls to X.
> >
> > Do you know why the connection was lost in the first place?
> 
> As far as I can tell, no X connection was lost.

Xlib obviously thinks otherwise, the error message in the backtrace is
very clear.

Message #20 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Sat, 08 Feb 2014 02:23:50 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Xlib obviously thinks otherwise, the error message in the backtrace is
> very clear.

Well, might not something have scribbled something somewhere to make X
believe the window is no longer viable?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #23 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, "Jan D." <jan.h.d <at> swipnet.se>
Cc: 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Sat, 08 Feb 2014 12:56:55 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16676 <at> debbugs.gnu.org
> Date: Sat, 08 Feb 2014 02:23:50 -0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Xlib obviously thinks otherwise, the error message in the backtrace is
> > very clear.
> 
> Well, might not something have scribbled something somewhere to make X
> believe the window is no longer viable?

I'm not an expert on this, so I don't know.  Jan, can you comment,
please?

Message #26 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "16676 <at> debbugs.gnu.org" <16676 <at> debbugs.gnu.org>
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Sat, 8 Feb 2014 17:40:21 +0100

Hi.

8 feb 2014 kl. 11:56 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: 16676 <at> debbugs.gnu.org
>> Date: Sat, 08 Feb 2014 02:23:50 -0800
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>>> Xlib obviously thinks otherwise, the error message in the backtrace is
>>> very clear.
>> 
>> Well, might not something have scribbled something somewhere to make X
>> believe the window is no longer viable?
> 
> I'm not an expert on this, so I don't know.  Jan, can you comment,
> please?

The io error handler is only called for fatal errors.  Any system call related to io in Xlib that fails
triggers a call to the error handler.  Xlib can not recover from this, so the connection is lost.
If something writes garbage into Xlibs data, anything can happen.

    Jan D. 

Message #29 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: larsi <at> gnus.org, 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Sat, 08 Feb 2014 19:47:53 +0200

> From: "Jan D." <jan.h.d <at> swipnet.se>
> Date: Sat, 8 Feb 2014 17:40:21 +0100
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
>  "16676 <at> debbugs.gnu.org" <16676 <at> debbugs.gnu.org>
> 
> The io error handler is only called for fatal errors.  Any system call related to io in Xlib that fails
> triggers a call to the error handler.  Xlib can not recover from this, so the connection is lost.
> If something writes garbage into Xlibs data, anything can happen.

Is it wise to issue further X calls in this situation?  Maybe we
should skip X calls when we delete the frame as result of such
problems.

Message #32 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Sat, 8 Feb 2014 19:55:11 +0100

Hi.

8 feb 2014 kl. 18:47 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> From: "Jan D." <jan.h.d <at> swipnet.se>
>> Date: Sat, 8 Feb 2014 17:40:21 +0100
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
>> "16676 <at> debbugs.gnu.org" <16676 <at> debbugs.gnu.org>
>> 
>> The io error handler is only called for fatal errors.  Any system call related to io in Xlib that fails
>> triggers a call to the error handler.  Xlib can not recover from this, so the connection is lost.
>> If something writes garbage into Xlibs data, anything can happen.
> 
> Is it wise to issue further X calls in this situation?  Maybe we
> should skip X calls when we delete the frame as result of such
> problems.

No, you can not do any calls.  In fact, if the I/O error handler returns, Xlib does exit.
That is why x_connection_closed does a longjump (throws an error).

	Jan D.

Message #35 received at 16676 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: 16676 <at> debbugs.gnu.org
Subject: Re: bug#16676: 24.3.50; Repeated but random hang
Date: Fri, 14 Nov 2014 16:37:12 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> This has happened to me a handful of times now.  I'm reading news, and
> then Emacs will suddenly halt.
>
> Connecting to Emacs with gdb gives me the backtrace below.  Emacs will
> consume 100% CPU at this point.
>
> I've got the Emacs connected to gdb if anybody wants me to output some
> data values...
>
> #0  0x0000003f4de29e3c in XIfEvent () from /lib64/libX11.so.6
> #1  0x0000003f4de706e4 in _XimXRead () from /lib64/libX11.so.6

I haven't seen this problem for half a year now, so I'm closing this report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.