[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16737: Yank causes hang in v24.4.1
From: |
Mike Crowe |
Subject: |
bug#16737: Yank causes hang in v24.4.1 |
Date: |
Tue, 11 Nov 2014 13:26:05 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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@entry=0x7fff51b23ee0) at
xselect.c:1147
1147 xselect.c: No such file or directory.
(gdb) bt
#0 x_handle_property_notify (event=event@entry=0x7fff51b23ee0) at
xselect.c:1147
#1 0x00000000004c3c20 in handle_one_xevent (dpyinfo=0x1a56800,
event=event@entry=0x7fff51b23ee0,
finish=finish@entry=0x7fff51b23e44, hold_quit=hold_quit@entry=0x0) at
xterm.c:6026
#2 0x00000000004c4dc0 in x_dispatch_event (event=event@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.