From: Spencer Baugh <sbaugh@janestreet.com>
To: Po Lu <luangruo@yahoo.com>
Cc: Eli Zaretskii <eliz@gnu.org>, 63865@debbugs.gnu.org
Subject: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes
Date: Sat, 03 Jun 2023 07:10:41 -0400 [thread overview]
Message-ID: <iermt1gajim.fsf@janestreet.com> (raw)
In-Reply-To: <87bkhxnhpk.fsf@yahoo.com> (Po Lu's message of "Sat, 03 Jun 2023 15:11:19 +0800")
Po Lu <luangruo@yahoo.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Spencer Baugh <sbaugh@janestreet.com>
>>> Date: Fri, 02 Jun 2023 21:55:09 -0400
>>>
>>>
>>> 1. Under X11, with the GTK or Lucid toolkits:
>>> emacs -Q
>>> 2. Become owner of the clipboard selection by killing some text; the
>>> starting comments in the scratch buffer are a good candidate.
>>> 3. Immediately afterwards (i.e. without copy and pasting text in another
>>> window), run:
>>> (call-process "sleep" nil nil nil "inf")
>>> 4. Now other applications will hang when they attempt to paste text.
>>> Google Chrome and Slack are two examples. (GTK-based applications
>>> seem to be fine. So much for proprietary software...)
>>
>> Thanks.
>>
>> Does this happen also with the latest pretest, v29.0.91?
>
> I can't reproduce this, but the closest thing to Google Chrome on the
> computer I am currently using is Firefox 10.0.7.
BTW, this can also be reproduced using just Emacs. If I try to paste in
another Emacs instead of in Google Chrome, I get a hang, followed by:
gui-get-selection: (error "Timed out waiting for reply from selection owner")
With -DTRACE_SELECTION on both Emacsen, the selection-owner Emacs prints
no logs, while the pasting Emacs prints the following log:
48866: Get selection UTF8_STRING, type _EMACS_TMP_
48866: Start waiting 5 secs for SelectionNotify.
48866: Waiting for 0 nsecs in addition.
48866: Got event = NO
48866: Get selection TIMESTAMP, type _EMACS_TMP_
48866: Start waiting 5 secs for SelectionNotify.
48866: Waiting for 0 nsecs in addition.
48866: Got event = NO
> So would you also build Emacs with -DTRACE_SELECTION, and show what is
> printed by Emacs when the requestor hangs?
Emacs prints nothing while stuck in call-process and the requestor
(Chrome) is hanging. After I interrupt call-process, this log prints.
48290: x_handle_selection_event
48290: XGetAtomName --> NULL
48290: XGetAtomName --> text/plain;charset=utf-8
48290: x_handle_selection_request: selection=CLIPBOARD, target=text/plain;charset=utf-8
48290: XInternAtom text/plain;charset=utf-8
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 70 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 70 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 70 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 70 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 23 elements directly to requestor window
48290: x_handle_selection_event
48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING
48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112
48290: x_start_selection_transfer: writing 70 elements directly to requestor window
next prev parent reply other threads:[~2023-06-03 11:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-03 1:55 bug#63865: 29.0.90; call-process while owning the X selection hangs other processes Spencer Baugh
2023-06-03 6:02 ` Eli Zaretskii
2023-06-03 7:11 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-03 9:12 ` Eli Zaretskii
2023-06-03 9:31 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-03 11:10 ` Spencer Baugh [this message]
2023-06-03 11:16 ` Eli Zaretskii
2023-06-03 12:07 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-03 12:30 ` Spencer Baugh
2023-06-03 12:55 ` Eli Zaretskii
2023-06-03 13:10 ` Spencer Baugh
2023-06-03 13:48 ` Eli Zaretskii
2023-06-03 14:12 ` Spencer Baugh
2023-06-03 14:24 ` Eli Zaretskii
2023-06-03 14:41 ` Spencer Baugh
2023-06-03 15:02 ` Eli Zaretskii
2023-06-03 15:34 ` Spencer Baugh
2023-06-03 15:50 ` Eli Zaretskii
2023-06-04 0:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-03 16:21 ` Andreas Schwab
2023-06-03 17:03 ` Spencer Baugh
2023-06-03 17:07 ` Eli Zaretskii
2023-06-04 0:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-04 0:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-04 0:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-23 14:26 ` Spencer Baugh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=iermt1gajim.fsf@janestreet.com \
--to=sbaugh@janestreet.com \
--cc=63865@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).