bug#22214: 25.0.50; lock up with gui dialogs and clipmon-mode

[Joseph Mingrone]

On Mon, 2022-05-23 at 10:02, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Po Lu <luangruo@yahoo.com> writes:

>> Joseph Mingrone <jrm@ftfl.ca> writes:

>>> I stopped using clipmon shortly after this bug was reported, but I just
>>> cloned the repository and ran

>>> % emacs -Q
>>> (load "/path/to/clipmon/clipmon.el")
>>> (run-at-time nil 2 (lambda () (gui-get-primary-selection)))
>>> (menu-set-font)

>>> When I dismissed the dialog box, sometimes things were fine, but other
>>> times, Emacs started to use 100% CPU and would not respond to input.
>>> Now I am able to kill the run-away emacs process and regain control of
>>> the system.  Below is information about my current installation.

>> Does this fix the problem?

> Joseph, did you have a chance to try Po's patch?


>> diff --git a/src/xselect.c b/src/xselect.c
>> index 6d167c0b6f..eb297e9cba 100644
>> --- a/src/xselect.c
>> +++ b/src/xselect.c
>> @@ -1255,7 +1255,9 @@ x_get_foreign_selection (Lisp_Object
>> selection_symbol, Lisp_Object target_type,
>>    int nsecs = (timeout % 1000) * 1000000;
>>    TRACE1 ("  Start waiting %"PRIdMAX" secs for SelectionNotify", secs);
>>    wait_reading_process_output (secs, nsecs, 0, false,
>> -                           reading_selection_reply, NULL, 0);
>> +                           /* Don't run any timers, since this
>> +                              code isn't reentrant.  */
>> +                           reading_selection_reply, NULL, -1);
>>    TRACE1 ("  Got event = %d", !NILP (XCAR (reading_selection_reply)));

>>    if (NILP (XCAR (reading_selection_reply)))

Hello all,

Sorry for the delay.  I lost track of this thread.

I just rebuilt 5a1a67a with the patch applied.  Using the same recipe as
above, when I tried to dismiss the dialog box emacs became unresponsive
and stared using 100% CPU.  I had to use xkill.

Joe