GNU bug report logs - #58505
29.0.50; Time out waiting for reply from selection owner

Previous Next

To reply to this bug, email your comments to 58505 AT debbugs.gnu.org.

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

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

From: Jean Louis <bugs <at> gnu.support>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Time out waiting for reply from selection owner
Date: Thu, 13 Oct 2022 15:27:50 +0300

There is problem when Emacs runs in separate instance while other
instance is running:

1. I launch one instance, and have there heavy process running and
 processing items. Because instance is fully busy, I launch new
 instance.

2. In the new instance when running kill-new I get errors like: Timed
out waiting for reply from selection owner

3. Other applications have no problem selecting, pasting, copying.


In GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.17.6, Xaw3d scroll bars) of 2022-10-10 built on
 protected.rcdrun.com
Repository revision: ed436db1320339862fad5ac754a6ec42de06c766
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Parabola GNU/Linux-libre

Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 39114 6879)
 (symbols 48 5153 2)
 (strings 32 14285 2207)
 (string-bytes 1 401515)
 (vectors 16 10401)
 (vector-slots 8 158354 11185)
 (floats 8 23 25)
 (intervals 56 256 0)
 (buffers 1000 11))

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

From: Po Lu <luangruo <at> yahoo.com>
To: Jean Louis <bugs <at> gnu.support>
Cc: 58505 <at> debbugs.gnu.org
Subject: Re: bug#58505: 29.0.50; Time out waiting for reply from selection
 owner
Date: Fri, 14 Oct 2022 14:23:29 +0800

Jean Louis <bugs <at> gnu.support> writes:

> There is problem when Emacs runs in separate instance while other
> instance is running:
>
> 1. I launch one instance, and have there heavy process running and
>  processing items. Because instance is fully busy, I launch new
>  instance.

This is a well known problem with our selection code that cannot be
easily fixed.  Process filters get to run while responding to selection
events, and (alongside the first Emacs instance being under high load in
general) can disrupt selection data transfer long enough for the second
instance to time out.

If the first instance is actually completely hung, then in addition
SelectionRequest events will never be read from the keyboard buffer, and
it will never get a chance to process selection requests at all.  I
don't see us ever being able to do anything about that problem.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 58505 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#58505: 29.0.50;
 Time out waiting for reply from selection owner
Date: Fri, 14 Oct 2022 09:26:51 +0300

> Cc: 58505 <at> debbugs.gnu.org
> Date: Fri, 14 Oct 2022 14:23:29 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Jean Louis <bugs <at> gnu.support> writes:
> 
> > There is problem when Emacs runs in separate instance while other
> > instance is running:
> >
> > 1. I launch one instance, and have there heavy process running and
> >  processing items. Because instance is fully busy, I launch new
> >  instance.
> 
> This is a well known problem with our selection code that cannot be
> easily fixed.  Process filters get to run while responding to selection
> events, and (alongside the first Emacs instance being under high load in
> general) can disrupt selection data transfer long enough for the second
> instance to time out.

The solution, of course, is to never run more than a single Emacs
session on the same machine.

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 58505 <at> debbugs.gnu.org
Subject: Re: bug#58505: 29.0.50; Time out waiting for reply from selection
 owner
Date: Sat, 15 Oct 2022 07:11:01 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2022-10-14 09:27]:
> The solution, of course, is to never run more than a single Emacs
> session on the same machine.

That is isolated solution for users who do not use Emacs Lisp for
heavy or continues processing of data.

Would process that runs in console or as batch also cause this
problem?

Is there a way in a single instance to disable something, so that
selection whatever is disabled during processing, so that other
instance is not disturbed?

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: luangruo <at> yahoo.com, 58505 <at> debbugs.gnu.org
Subject: Re: bug#58505: 29.0.50; Time out waiting for reply from selection
 owner
Date: Sat, 15 Oct 2022 10:39:01 +0300

> Date: Sat, 15 Oct 2022 07:11:01 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Po Lu <luangruo <at> yahoo.com>, 58505 <at> debbugs.gnu.org
> 
> * Eli Zaretskii <eliz <at> gnu.org> [2022-10-14 09:27]:
> > The solution, of course, is to never run more than a single Emacs
> > session on the same machine.
> 
> That is isolated solution for users who do not use Emacs Lisp for
> heavy or continues processing of data.

I disagree with this assertion.  You can organize your heavy
computation such that it never runs when you need an interactive
session, or run such computation in a sub-process (that could also be
Emacs, just one running in batch mode), or any number of other
solutions.  You just need to realize that having just one interactive
Emacs session at a time is much more important than the other
considerations, and change your priorities accordingly.

> Would process that runs in console or as batch also cause this
> problem?

I don't think so, no.

> Is there a way in a single instance to disable something, so that
> selection whatever is disabled during processing, so that other
> instance is not disturbed?

You can disable interprogram-paste-function, but why would you want
to?

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 58505 <at> debbugs.gnu.org
Subject: Re: bug#58505: 29.0.50; Time out waiting for reply from selection
 owner
Date: Sun, 16 Oct 2022 16:01:37 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2022-10-15 10:39]:
> > Date: Sat, 15 Oct 2022 07:11:01 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: Po Lu <luangruo <at> yahoo.com>, 58505 <at> debbugs.gnu.org
> > 
> > * Eli Zaretskii <eliz <at> gnu.org> [2022-10-14 09:27]:
> > > The solution, of course, is to never run more than a single Emacs
> > > session on the same machine.
> > 
> > That is isolated solution for users who do not use Emacs Lisp for
> > heavy or continues processing of data.
> 
> I disagree with this assertion.  You can organize your heavy
> computation such that it never runs when you need an interactive
> session, or run such computation in a sub-process (that could also be
> Emacs, just one running in batch mode), or any number of other
> solutions.  You just need to realize that having just one interactive
> Emacs session at a time is much more important than the other
> considerations, and change your priorities accordingly.

That is exactly what I do, I span one Emacs session as separate
instance. What I do not understand is how that separate instance may
disturb the new instance to yank or use selections. I do not know if
it wants to use selections, but similar wording was written in
messages. I hope you understand it better. Other X programs do not
have the problem in copying or pasting while Emacs is processing
information in the database.

> > Would process that runs in console or as batch also cause this
> > problem?
> 
> I don't think so, no.
> 
> > Is there a way in a single instance to disable something, so that
> > selection whatever is disabled during processing, so that other
> > instance is not disturbed?
> 
> You can disable interprogram-paste-function, but why would you want
> to?

The bug report is the reason why I would want it. When Emacs is
processing heavy data, I do not write nothing in that instance, I
cannot access the instance, it is blocked due to processing. That is
fine. But then I want to use other instance, and that other instance,
the interactive one, gets disturbed because during the processing of
the first instance something is happening and second instance,
supposed to be free, is not free for work.

Thus I guess if I disable interprogram-paste-function in the
processing instance, new instance should not have problems.

I have tested it now. It does not work. I have disabled both
variables, interprogram-paste and cut function, and I have spanned new
Emacs instance.

I get this error again:

gui-get-selection: (error "Timed out waiting for reply from selection owner")
Timed out waiting for reply from selection owner

I wish to disable it in the instance processing with Emacs Lisp, not
in the one which I need for interactive usage.

What else is possible to do to make it work?

My Emacs is supposed to run 24 hours processing advertising
information.

Processing instance screenshot:
https://gnu.support/images/2022/10/2022-10-16/2022-10-16-15:35:07.png

That frame I do not touch as Emacs is not responsive, it just does Emacs Lisp.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

From: Po Lu <luangruo <at> yahoo.com>
To: Jean Louis <bugs <at> gnu.support>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58505 <at> debbugs.gnu.org
Subject: Re: bug#58505: 29.0.50; Time out waiting for reply from selection
 owner
Date: Mon, 17 Oct 2022 09:32:52 +0800

Then as I've repeatedly asked, please build Emacs with TRACE_SELECTION
defined in xselect.c, and show the printout when it times out.

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

From: daanturo <daanturo <at> gmail.com>
To: eliz <at> gnu.org
Cc: 58505 <at> debbugs.gnu.org
Subject: bug#58505: 29.0.50; Time out waiting for reply from selection owner
Date: Sun, 13 Nov 2022 00:52:25 +0700

[Message part 1 (text/plain, inline)]

>  You can disable interprogram-paste-function, but why would you want

> to?

Are there any downsizes to disabling in `noninteractive` sessions only (if I have
control there)?

This bug is killing me as sometimes even when all other Emacs instances are
killed, copying and pasting still hangs Emacs until I log out of the DE and log
in again.

-- 
Daanturo.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: daanturo <daanturo <at> gmail.com>
Cc: 58505 <at> debbugs.gnu.org
Subject: Re: bug#58505: 29.0.50;
 Time out waiting for reply from selection owner
Date: Sat, 12 Nov 2022 20:13:54 +0200

> Date: Sun, 13 Nov 2022 00:52:25 +0700
> Cc: 58505 <at> debbugs.gnu.org
> From: daanturo <daanturo <at> gmail.com>
> 
> 
> >  You can disable interprogram-paste-function, but why would you want 
> 
> > to?
> 
> Are there any downsizes to disabling in `noninteractive` sessions only (if I have
> control there)?

If you don't care about copy/paste to or from other applications,
none.

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

From: Daan Ro <daanturo <at> gmail.com>
To: 58505 <at> debbugs.gnu.org
Subject: Fwd: bug#58505: 29.0.50;
 Time out waiting for reply from selection owner
Date: Sun, 13 Nov 2022 12:11:46 +0700

[Message part 1 (text/plain, inline)]

---------- Forwarded message ---------
From: Daan Ro <daanturo <at> gmail.com>
Date: Sun, Nov 13, 2022 at 12:01 PM
Subject: Re: bug#58505: 29.0.50; Time out waiting for reply from selection
owner
To: Eli Zaretskii <eliz <at> gnu.org>


Then how about we do that by default, since batch sessions are untouchable
in
the user-space.

If a non-interactive instance really needs to access the clipboard (which
normally doesn't), it can easily set `interprogram-paste-function`.
Disabling
prevents those sessions from influencing the primary interactive one
(doesn't
solve the problem for multiple interactive instances, though).

I am experimenting with this patch.

On Sun, Nov 13, 2022 at 1:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Are there any downsizes to disabling in `noninteractive` sessions only
> (if I have
> > control there)?
>
> If you don't care about copy/paste to or from other applications,
> none.
>

Update: That patch will simply disable interprogram-paste-function
universally,
I need to find a more sophisticated approach.

-- 
Daanturo.

[Message part 2 (text/html, inline)]

[0001-Disable-interprogram-paste-function-when-noninteract.patch (application/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daan Ro <daanturo <at> gmail.com>
Cc: 58505 <at> debbugs.gnu.org
Subject: Re: bug#58505: 29.0.50;
 Time out waiting for reply from selection owner
Date: Sun, 13 Nov 2022 09:21:05 +0200

> From: Daan Ro <daanturo <at> gmail.com>
> Date: Sun, 13 Nov 2022 12:11:46 +0700
> 
> Then how about we do that by default, since batch sessions are untouchable in
> the user-space.

That makes little sense to me.  We shouldn't disable features in the
batch sessions without good reasons.  This works for almost everyone,
so changing the behavior for the benefit of a few that have some local
configuration issue is not TRT.

You can always disable this in your programs that you run in batch
mode.

> If a non-interactive instance really needs to access the clipboard (which
> normally doesn't), it can easily set `interprogram-paste-function`. Disabling
> prevents those sessions from influencing the primary interactive one (doesn't
> solve the problem for multiple interactive instances, though).
> 
> I am experimenting with this patch.

Sorry, this is a non-starter from my POV.  We will not change the
long-time default behavior because someone has local problems on their
system.

Previous Next

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