GNU bug report logs - #16737
24.3.50; Yank causes hang

Previous Next

Full log

View this message in rfc822 format

From: Mike Crowe <mac <at> mcrowe.com>
To: 16737 <at> debbugs.gnu.org
Subject: bug#16737: Yank causes hang in v24.4.1
Date: Tue, 11 Nov 2014 13:26:05 +0000

On Tuesday 11 November 2014 at 12:37:50 +0000, Mike Crowe wrote:
> > I still see it and I've been tracking the emacs-24 branch. It seems to be
> > a consequence of a long lived Emacs daemon session - I.e. any given
> > daemon eventually starts to timeout with x pastes. I just restart the
> > daemon and it goes away. I haven't restarted X/i3 for weeks.
> 
> I'm running Debian Jessie's "GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+
> Version 3.14.3)" in daemon mode. I rebooted yesterday and I'm seeing this
> problem today (in fact, I think I saw it late yesterday too.) I have seen
> the problem in earlier Debian Jessie Emacs versions too (v24.3)
> 
> I'm also running with i3 as my window manager.

I forgot to mention that I connect to Emacs both from a tty and X. The X
client stays active all the time. The tty ones come and go.

I attached with gdb and set a breakpoint on x_handle_property_notify as
suggested by the patch in message #55. When it fired:

Breakpoint 1, x_handle_property_notify (event=event <at> entry=0x7fff51b23ee0) at xselect.c:1147
1147	   xselect.c: No such file or directory.
(gdb) bt
#0  x_handle_property_notify (event=event <at> entry=0x7fff51b23ee0) at xselect.c:1147
#1  0x00000000004c3c20 in handle_one_xevent (dpyinfo=0x1a56800, event=event <at> entry=0x7fff51b23ee0, 
    finish=finish <at> entry=0x7fff51b23e44, hold_quit=hold_quit <at> entry=0x0) at xterm.c:6026
#2  0x00000000004c4dc0 in x_dispatch_event (event=event <at> entry=0x7fff51b23ee0, display=<optimized out>)
    at xterm.c:6951
#3  0x00000000004c4ed9 in event_handler_gdk (gxev=0x7fff51b23ee0, ev=<optimized out>, data=<optimized out>)
    at xterm.c:5727
#4  0x00007fb5c1164a51 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#5  0x00007fb5c1164d11 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x00007fb5c113b879 in gdk_display_get_event () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#7  0x00007fb5c1164ad2 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#8  0x00007fb5bfac0c5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
[...]
(gdb) p event->state
$1 = 0
(gdb) p (char *)XGetAtomName(event->display, event->atom)
$3 = 0x2772080 "_EMACS_TMP_"
(gdb) p event->window
$4 = 44040303
(gdb) p event->display
$5 = (Display *) 0x1883410
(gdb) p property_change_wait_list
$6 = (struct prop_location *) 0x0

I continued a few times and property_change_wait_list was always NULL.

I set another breakpoint on x_handle_property_notify only if
property_change_wait_list was non-NULL and it never fired when pasting into
Emacs.

Is there anything else I can usefully determine without recompiling?

Thanks.

Mike.

Previous Next

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