bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[Suvayu Ali]

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.

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[David De La Harpe Golden]

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@debbugs...) in 
the to/cc list for this thread, then it gets archived by the bug tracker.

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[Stefan Monnier]

> 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

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[Suvayu Ali]

Hello David,

On Mon, 30 May 2011 22:13:20 +0100
David De La Harpe Golden <david@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@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.

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[David De La Harpe Golden]

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."

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[Suvayu Ali]

Hi David,

On Tue, 31 May 2011 03:58:02 +0100
David De La Harpe Golden <david@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.

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[Chong Yidong]

David De La Harpe Golden <david@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);
      }
  }
  

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[David De La Harpe Golden]

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"

bug#8760: 24.0.50; Cannot kill emacs after killing text to kill-ring

[Chong Yidong]

David De La Harpe Golden <david@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.