GNU bug report logs -
#8760
24.0.50; Cannot kill emacs after killing text to kill-ring
Previous Next
Reported by: Suvayu Ali <fatkasuvayu+linux <at> gmail.com>
Date: Mon, 30 May 2011 07:14:01 UTC
Severity: normal
Merged with 8779
Found in version 24.0.50
Done: Chong Yidong <cyd <at> stupidchicken.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8760 in the body.
You can then email your comments to 8760 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Mon, 30 May 2011 07:14:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Suvayu Ali <fatkasuvayu+linux <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 30 May 2011 07:14:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Emacs developers,
After I updated Emacs today, I found a very annoying bug.
If I copy/kill something to the kill-ring, I can't exit emacs with 'C-x
C-c'. Attempting to do so results in the following backtrace:
Debugger entered--Lisp error: (error "Timed out waiting for reply from
selection owner") kill-emacs()
save-buffers-kill-emacs(nil)
save-buffers-kill-terminal(nil)
call-interactively(save-buffers-kill-terminal nil nil)
I have to kill emacs from the terminal or with xkill. When trying to
kill from the terminal, I have to execute the kill command twice like
this:
$ kill %1
$ kill %1
I observe this behaviour with emacs -Q. I am not subscribed to the dev
list, so if you wish any more information please feel free to contact me
directly.
Thanks a lot.
Suvayu
In GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4)
of 2011-05-29 on bhishma.homelinux.net
Windowing system distributor `Fedora Project', version 11.0.11001000
configured using `configure '--prefix=/opt/emacs-lisp'
'--with-selinux' '--with-imagemagick''
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_IN.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<down> <down> <down> C-M-f C-x C-e <home> <up> <up>
<up> C-SPC <C-down> <up> <up> <up> <up> <down> <down>
<down> <down> M-w C-x C-c <help-echo> <help-echo> <up>
<up> <up> <up> <up> <up> <up> C-SPC <down> <down> <down>
<down> <down> M-w <up> q M-x r e p o <tab> t <tab>
<backspace> r <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading vc-git...done
nil
Mark set
(No files need saving)
Entering debugger...
byte-code: Beginning of buffer [2 times]
Mark set
Back to top level.
Making completion list...
Load-path shadows:
/opt/emacs-lisp/share/emacs/site-lisp/flim/hex-util
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/hex-util /opt/emacs-lisp/share/emacs/site-lisp/flim/md4
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/md4 /opt/emacs-lisp/share/emacs/site-lisp/flim/ntlm
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/net/ntlm /opt/emacs-lisp/share/emacs/site-lisp/flim/sasl
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/net/sasl /opt/emacs-lisp/share/emacs/site-lisp/flim/sasl-digest
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/net/sasl-digest /opt/emacs-lisp/share/emacs/site-lisp/flim/sasl-cram
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/net/sasl-cram /opt/emacs-lisp/share/emacs/site-lisp/flim/sasl-ntlm
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/net/sasl-ntlm /opt/emacs-lisp/share/emacs/site-lisp/flim/hmac-md5
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/net/hmac-md5 /opt/emacs-lisp/share/emacs/site-lisp/flim/hmac-def
hides /opt/emacs-lisp/share/emacs/24.0.50/lisp/net/hmac-def
Features:
(shadow sort gnus-util time-date mail-extr message idna sendmail
regexp-opt format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mailabbrev mail-utils gmm-utils mailheader emacsbug help-mode easymenu
view debug vc-git tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image fringe lisp-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 loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)
--
Suvayu
Open source is the future. It sets us free.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Mon, 30 May 2011 21:14:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 8760 <at> debbugs.gnu.org (full text, mbox):
On 30/05/11 08:12, Suvayu Ali wrote:
> Hi Emacs developers,
>
> After I updated Emacs today, I found a very annoying bug.
>
> If I copy/kill something to the kill-ring, I can't exit emacs with 'C-x
> C-c'. Attempting to do so results in the following backtrace:
>
> Debugger entered--Lisp error: (error "Timed out waiting for reply from
> selection owner") kill-emacs()
> save-buffers-kill-emacs(nil)
> save-buffers-kill-terminal(nil)
> call-interactively(save-buffers-kill-terminal nil nil)
>
*** What desktop environment do you use, if any? (KDE, GNOME, XFCE, ...)
(and what version?)
Emacs was just expanded to communicate with a desktop environment's
clipboard manager if available, which allows things you copy to persist
on the clipboard after you exit emacs.
However, in your case something is going wrong, it sounds like you have
a daemon around claiming to be a clipboard manager (because emacs is
trying to talk to it at all) but it's acting weird (emacs getting a
timeout trying to talk with it).
I can simulate this failure by pausing (kill -STOP/-CONT) my desktop
environment's clipboard manager - that way, it looks like there's an
owner of the clipboard manager selection that is unresponsive.
Arguably, emacs, if it's in the middle of exiting, could just carry on
exiting after the selection timeout period in case it fails to interact
with a present but uncommunicative clipboard manager, not fail to exit.
Then the worst that happens in case of a malfunctioning desktop
clipboard manager is a brief pause on exit (and of course a failure to
persist clipboard contents after exit, but, well, one can't expect that
to work if the desktop clipboard manager isn't working).
> I am not subscribed to the dev list
Please just be sure to keep the bug email address (8760 <at> debbugs...) in
the to/cc list for this thread, then it gets archived by the bug tracker.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Mon, 30 May 2011 22:37:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 8760 <at> debbugs.gnu.org (full text, mbox):
> Arguably, Emacs, if it's in the middle of exiting, could just carry on
> exiting after the selection timeout period in case it fails to interact
> with a present but uncommunicative clipboard manager, not fail
> to exit.
That would the right behavior, tho it's also important to somehow warn
the user about the problem. Yes, could someone do that?
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Tue, 31 May 2011 01:17:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 8760 <at> debbugs.gnu.org (full text, mbox):
Hello David,
On Mon, 30 May 2011 22:13:20 +0100
David De La Harpe Golden <david <at> harpegolden.net> wrote:
> On 30/05/11 08:12, Suvayu Ali wrote:
> > Hi Emacs developers,
> >
> > After I updated Emacs today, I found a very annoying bug.
> >
> > If I copy/kill something to the kill-ring, I can't exit emacs with
> > 'C-x C-c'. Attempting to do so results in the following backtrace:
> >
> > Debugger entered--Lisp error: (error "Timed out waiting for reply
> > from selection owner") kill-emacs()
> > save-buffers-kill-emacs(nil)
> > save-buffers-kill-terminal(nil)
> > call-interactively(save-buffers-kill-terminal nil nil)
> >
>
> *** What desktop environment do you use, if any? (KDE, GNOME,
> XFCE, ...) (and what version?)
>
I use XFCE with the clipman plugin (its a clipboard manager).
> Emacs was just expanded to communicate with a desktop environment's
> clipboard manager if available, which allows things you copy to
> persist on the clipboard after you exit emacs.
>
Yes I had noticed that over the last month or two. It was working very
well until now.
> However, in your case something is going wrong, it sounds like you
> have a daemon around claiming to be a clipboard manager (because
> emacs is trying to talk to it at all) but it's acting weird (emacs
> getting a timeout trying to talk with it).
>
> I can simulate this failure by pausing (kill -STOP/-CONT) my desktop
> environment's clipboard manager - that way, it looks like there's an
> owner of the clipboard manager selection that is unresponsive.
>
I tried the same steps in a fresh XFCE session without clipman, I
still get the same results. I am not very familiar with the internals
of XFCE, not sure how the default XFCE clipboard is managed.
> Arguably, emacs, if it's in the middle of exiting, could just carry
> on exiting after the selection timeout period in case it fails to
> interact with a present but uncommunicative clipboard manager, not
> fail to exit. Then the worst that happens in case of a malfunctioning
> desktop clipboard manager is a brief pause on exit (and of course a
> failure to persist clipboard contents after exit, but, well, one
> can't expect that to work if the desktop clipboard manager isn't
> working).
>
That would be a reasonable behaviour. :)
> > I am not subscribed to the dev list
>
> Please just be sure to keep the bug email address (8760 <at> debbugs...)
> in the to/cc list for this thread, then it gets archived by the bug
> tracker.
>
Thanks for that tip, will keep that in mind from now.
For some reason I did not get your or Stefan's response despite both of
you CC'ing me. I downloaded your message from the bug tracker and am
responding to it so the threading might be screwed up. Its probably a
Gmail issue.
Thanks,
--
Suvayu
Open source is the future. It sets us free.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Tue, 31 May 2011 02:59:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 8760 <at> debbugs.gnu.org (full text, mbox):
On 31/05/11 02:15, Suvayu Ali wrote:
> I tried the same steps in a fresh XFCE session without clipman, I
> still get the same results.
That does suggest it's a problem with xfce's default clipboard manager.
They recently reimplemented that. You may still be running an older
known-buggy one.
> I am not very familiar with the internals
> of XFCE, not sure how the default XFCE clipboard is managed.
There's a clipboard manager hiding inside xfce4-settings-helper.
Please try the following command at the shell to print its version and
report the results:
xfce4-settings-helper -V
If it's less than 4.8.2, you may have the buggy version. It can cause
similar problems with other apps too [1]. (That doesn't change the fact
emacs should be exiting after timing out, of course).
> For some reason I did not get your or Stefan's response despite both of
> you CC'ing me. I downloaded your message from the bug tracker and am
> responding to it so the threading might be screwed up. Its probably a
> Gmail issue.
>
Irritating. FWIW, my mailserver says it successfully handed the mail to
google. Hopefully this one will reach you less awkwardly.
[1] https://bugzilla.xfce.org/show_bug.cgi?id=7588
"xfce4-settings-4.8.2 contains the gsd clipboard that should resolve
this bug."
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Tue, 31 May 2011 03:50:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 8760 <at> debbugs.gnu.org (full text, mbox):
Hi David,
On Tue, 31 May 2011 03:58:02 +0100
David De La Harpe Golden <david <at> harpegolden.net> wrote:
> On 31/05/11 02:15, Suvayu Ali wrote:
>
> > I am not very familiar with the internals
> > of XFCE, not sure how the default XFCE clipboard is managed.
>
> There's a clipboard manager hiding inside xfce4-settings-helper.
> Please try the following command at the shell to print its version
> and report the results:
>
> xfce4-settings-helper -V
>
> If it's less than 4.8.2, you may have the buggy version. It can cause
> similar problems with other apps too [1]. (That doesn't change the
> fact emacs should be exiting after timing out, of course).
>
xfce4-settings-helper 4.8.1 (Xfce 4.8.0)
My version is indeed the buggy version. I am on Fedora 15, I will take
this up with the Fedora XFCE team.
> > For some reason I did not get your or Stefan's response despite
> > both of you CC'ing me. I downloaded your message from the bug
> > tracker and am responding to it so the threading might be screwed
> > up. Its probably a Gmail issue.
> >
>
> Irritating. FWIW, my mailserver says it successfully handed the mail
> to google. Hopefully this one will reach you less awkwardly.
>
This one reached properly. :)
Thanks a lot. I hope I have provided enough information to fix the Emacs
end of this issue. :)
--
Suvayu
Open source is the future. It sets us free.
Merged 8760 8779.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Wed, 01 Jun 2011 07:30:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Wed, 01 Jun 2011 19:02:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 8760 <at> debbugs.gnu.org (full text, mbox):
David De La Harpe Golden <david <at> harpegolden.net> writes:
> I can simulate this failure by pausing (kill -STOP/-CONT) my desktop
> environment's clipboard manager - that way, it looks like there's an
> owner of the clipboard manager selection that is unresponsive.
>
> Arguably, emacs, if it's in the middle of exiting, could just carry on
> exiting after the selection timeout period in case it fails to
> interact with a present but uncommunicative clipboard manager, not
> fail to exit. Then the worst that happens in case of a malfunctioning
> desktop clipboard manager is a brief pause on exit (and of course a
> failure to persist clipboard contents after exit, but, well, one can't
> expect that to work if the desktop clipboard manager isn't working).
Right. Does this patch handle your test case properly?
One concern I have is that even if the clipboard manager is screwing up,
it will appear as though it's Emacs' fault for taking ages to delete a
frame and/or shut down. Dunno how we can inform the user, though.
=== modified file 'src/xselect.c'
*** src/xselect.c 2011-05-29 05:23:24 +0000
--- src/xselect.c 2011-06-01 18:55:25 +0000
***************
*** 2112,2122 ****
UTF8_STRING property, as described by
http://www.freedesktop.org/wiki/ClipboardManager */
! static void
! x_clipboard_manager_save (struct x_display_info *dpyinfo,
! Lisp_Object frame)
{
struct frame *f = XFRAME (frame);
Atom data = dpyinfo->Xatom_UTF8_STRING;
XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
--- 2112,2122 ----
UTF8_STRING property, as described by
http://www.freedesktop.org/wiki/ClipboardManager */
! static Lisp_Object
! x_clipboard_manager_save (Lisp_Object frame)
{
struct frame *f = XFRAME (frame);
+ struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f);
Atom data = dpyinfo->Xatom_UTF8_STRING;
XChangeProperty (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
***************
*** 2148,2154 ****
&& EQ (frame, XCAR (XCDR (XCDR (XCDR (local_selection)))))
&& XGetSelectionOwner (dpyinfo->display,
dpyinfo->Xatom_CLIPBOARD_MANAGER))
! x_clipboard_manager_save (dpyinfo, frame);
}
}
--- 2148,2155 ----
&& EQ (frame, XCAR (XCDR (XCDR (XCDR (local_selection)))))
&& XGetSelectionOwner (dpyinfo->display,
dpyinfo->Xatom_CLIPBOARD_MANAGER))
! internal_condition_case_1 (x_clipboard_manager_save,
! frame, Qt, Fidentity);
}
}
***************
*** 2172,2178 ****
local_frame = XCAR (XCDR (XCDR (XCDR (local_selection))));
if (FRAME_LIVE_P (XFRAME (local_frame)))
! x_clipboard_manager_save (dpyinfo, local_frame);
}
}
--- 2173,2180 ----
local_frame = XCAR (XCDR (XCDR (XCDR (local_selection))));
if (FRAME_LIVE_P (XFRAME (local_frame)))
! internal_condition_case_1 (x_clipboard_manager_save,
! local_frame, Qt, Fidentity);
}
}
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Thu, 02 Jun 2011 03:02:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 8760 <at> debbugs.gnu.org (full text, mbox):
On 01/06/11 20:01, Chong Yidong wrote:
> Right. Does this patch handle your test case properly?
Yes, deleting frames and exiting, though of course there's the expected
pause. It is quite long enough that people will notice and probably file
bug reports. But I don't think reducing the timeout much is a good idea
either, people after all could genuinely be on a slow connection...
> One concern I have is that even if the clipboard manager is screwing up,
> it will appear as though it's Emacs' fault for taking ages to delete a
> frame and/or shut down.
Indeed.
> Dunno how we can inform the user, though.
Well, for the x_clipboard_manager_save_frame case, then a normal message
should suffice? they'll see it in another of their remaining frames.
For the x_clipboard_manager_save_all - printing something to the emacs
process stderr before exit might be simplest. But could be missed.
Popping up dialogs / interactive prompts seems overly intrusive to me,
but is probably an option.
I suppose one could show a message too - if one messaged before starting
the save, then it would rapidly flash by except in the case it's taking
ages, but at least bug reports would come in with the text of the
message. Except that means letting redisplay happen...
If the user has sat through the timeout, showing a message for a few
secs post-timeout is only a small incremental time wasting, but still
involves letting more redisplay happen.
What to say?
"Timeout communicating with your desktop environment clipboard manager"
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8760
; Package
emacs
.
(Sat, 04 Jun 2011 21:05:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 8760 <at> debbugs.gnu.org (full text, mbox):
David De La Harpe Golden <david <at> harpegolden.net> writes:
> Well, for the x_clipboard_manager_save_frame case, then a normal
> message should suffice? they'll see it in another of their remaining
> frames.
>
> For the x_clipboard_manager_save_all - printing something to the emacs
> process stderr before exit might be simplest.
I guess that's the best we can hope for. I've committed some changes to
handle clipboard manager errors in this way. I'm closing this bug; we
can consider Bug#8779 separately.
bug closed, send any further explanations to
8760 <at> debbugs.gnu.org and Suvayu Ali <fatkasuvayu+linux <at> gmail.com>
Request was from
Chong Yidong <cyd <at> stupidchicken.com>
to
control <at> debbugs.gnu.org
.
(Sat, 04 Jun 2011 21:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 20 Jul 2011 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.