bug#29170: 26.0.90; Emacs freezes when capturing an org-template

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Grégoire Jadi]

Hello,

For some time now (emacs-25.1), emacs freezes when I use `org-capture'.
The problem occurs when emacs tries to read the SECONDARY selection.

The following snippet can be used to freeze emacs for 2s everytime on my
computer :
(let ((value 'SECONDARY)
      (x-selection-timeout 2000))
  ;;; from org-get-x-clipboard in lisp/org-compat.el
  (gui-get-selection value 'UTF8_STRING)
  (gui-get-selection value 'COMPOUND_TEXT)
  (gui-get-selection value 'STRING)
  (gui-get-selection value 'TEXT))

If the user (me) send any commands (C-p, C-n, M-x, ...) to emacs when it
is frozen, Emacs will stay frozen even after the 2s timeout.
Most of the time, it is possible to recover from the freeze by sending
SIGUSR2 to the emacs process.
The backtrace is :

Debugger entered--Lisp error: (quit)
  x-get-selection-internal(SECONDARY STRING nil nil)
  #f(compiled-function (selection-symbol target-type &optional time-stamp terminal) #<bytecode 0x564065>)(SECONDARY STRING)
  apply(#f(compiled-function (selection-symbol target-type &optional time-stamp terminal) #<bytecode 0x564065>) (SECONDARY STRING))
  gui-backend-get-selection(SECONDARY STRING)
  gui-get-selection(SECONDARY STRING)
  (let ((value 'SECONDARY) (x-selection-timeout 2000)) (gui-get-selection value 'UTF8_STRING) (gui-get-selection value 'COMPOUND_TEXT) (gui-get-selection value 'STRING) (gui-get-selection value 'TEXT))
  eval((let ((value 'SECONDARY) (x-selection-timeout 2000)) (gui-get-selection value 'UTF8_STRING) (gui-get-selection value 'COMPOUND_TEXT) (gui-get-selection value 'STRING) (gui-get-selection value 'TEXT)) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

I've done some experiments :
- Any *single* call of `gui-get-selection' will not freeze emacs for 2s.
- Any *combination of two* calls of `gui-get-selection' will freeze
  emacs for 2s but it will just stops if any command is sent (C-p, C-n,
  ...).
- Any *combination of three or four* calls of `gui-get-selection' will
  freeze emacs for 2s and freeze emacs completely if any command is sent
  (C-p, C-n, ...).
But I've no idea where to look to find out how to fix this problem.
Please, tell me how I can help.

I'm using Emacs 26.0.90 with Gtk3 on OpenBSD 6.2-current (GENERIC.MP).

Best,


In GNU Emacs 26.0.90 (build 1, x86_64-unknown-openbsd, GTK+ Version 3.22.24)
 of 2017-10-29 built on puffy
Repository revision: 6361151a84d643d4a5d658f740dac5809c682704
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000

Configured using:
 'configure --build=amd64-unknown-openbsd --without-sound
 --with-x-toolkit=gtk3 --prefix=/usr/local --sysconfdir=/etc
 --mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var
 --disable-silent-rules --disable-gtk-doc 'CFLAGS=-O2 -pipe -fno-pie'
 CPPFLAGS=-I/usr/local/include 'LDFLAGS=-L/usr/local/lib -nopie''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GSETTINGS NOTIFY GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 LCMS2

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_COLLATE: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Piotr Isajew]

Adding to the original report - I've noticed an issue which may
also relate to the same problem.

I'm using org-capture on OpenBSD under X11. M-x org-capture
displays a list of capture templates. On any other system I have
access to, or even on OpenBSD console, pressing a template letter
will open a capture buffer. On X11 however it hangs until I move
mouse. This was observed for Emacs 25 and 26 on OpenBSD
only. Additionally there are some situations when Emacs will just
hang in an infinite loop. There's no way to interrupt this, other
than SIGKILL.

I'm attaching stacktraces for such a situation:

info thre
  4 thread 424274  _thread_sys_poll () at -:3
  3 thread 437321  _thread_sys_poll () at -:3
* 2 thread 476142  _thread_sys_poll () at -:3
  1 thread 131181  wait_reading_process_output (time_limit=5, nsecs=0, 
    read_kbd=0, do_display=false, wait_for_cell=16374659, wait_proc=0x0, 
    just_wait_proc=0) at process.c:5296
(gdb) thr 4
[Switching to thread 4 (thread 424274)]#0  _thread_sys_poll () at -:3
3       in -
(gdb) inf sta
#0  _thread_sys_poll () at -:3
#1  0x00000002c6d1f45f in _libc_poll_cancel (fds=Variable "fds" is not available.
)
    at /usr/src/lib/libc/sys/w_poll.c:27
#2  0x000000022d883497 in g_main_context_iterate () at gmain.c:4271
#3  0x000000022d883594 in g_main_context_iteration (context=0x20ddb0500, 
    may_block=The value of variable 'may_block' is distributed across several
locations, and GDB cannot access its value.

) at gmain.c:4033
#4  0x00000002c7f2bb7d in g_io_module_query ()
   from /usr/local/lib/gio/modules/libdconfsettings.so
#5  0x000000022d8ac3fa in g_thread_proxy (data=0x259d50190) at gthread.c:784
#6  0x0000000275642cae in _rthread_start (v=Variable "v" is not available.
)
    at /usr/src/lib/librthread/rthread.c:96
#7  0x00000002c6d1b96b in __tfork_thread ()
    at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#8  0x0000000000000000 in ?? ()

(gdb) thr 3
[Switching to thread 3 (thread 437321)]#0  _thread_sys_poll () at -:3
3       in -
(gdb) inf sta
#0  _thread_sys_poll () at -:3
#1  0x00000002c6d1f45f in _libc_poll_cancel (fds=Variable "fds" is not available.
)
    at /usr/src/lib/libc/sys/w_poll.c:27
#2  0x000000022d883497 in g_main_context_iterate () at gmain.c:4271
#3  0x000000022d883594 in g_main_context_iteration (context=0x243a3ce00, 
    may_block=The value of variable 'may_block' is distributed across several
locations, and GDB cannot access its value.

) at gmain.c:4033
#4  0x000000022d885296 in glib_worker_main (data=Variable "data" is not available.
) at gmain.c:5824
#5  0x000000022d8ac3fa in g_thread_proxy (data=0x259d50000) at gthread.c:784
#6  0x0000000275642cae in _rthread_start (v=Variable "v" is not available.
)
    at /usr/src/lib/librthread/rthread.c:96
#7  0x00000002c6d1b96b in __tfork_thread ()
    at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75

(gdb) thr 2
[Switching to thread 2 (thread 476142)]#0  _thread_sys_poll () at -:3
3       in -
(gdb) inf sta
#0  _thread_sys_poll () at -:3
#1  0x00000002c6d1f45f in _libc_poll_cancel (fds=Variable "fds" is not available.
)
    at /usr/src/lib/libc/sys/w_poll.c:27
#2  0x000000022d883497 in g_main_context_iterate () at gmain.c:4271
#3  0x000000022d88382f in g_main_loop_run (loop=0x249a70a80) at gmain.c:4168
#4  0x00000002a5dac8cb in gdbus_shared_thread_func (user_data=0x2039baa80)
    at gdbusprivate.c:252
#5  0x000000022d8ac3fa in g_thread_proxy (data=0x27f39fed0) at gthread.c:784
#6  0x0000000275642cae in _rthread_start (v=Variable "v" is not available.
)
    at /usr/src/lib/librthread/rthread.c:96
#7  0x00000002c6d1b96b in __tfork_thread ()
    at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#8  0x0000000000000000 in ?? ()


(gdb) thr 1
[Switching to thread 1 (thread 131181)]#0  wait_reading_process_output (
    time_limit=5, nsecs=0, read_kbd=0, do_display=false, 
    wait_for_cell=16374659, wait_proc=0x0, just_wait_proc=0) at process.c:5296
5296              FD_ZERO (&Available);
Current language:  auto; currently minimal
(gdb) inf sta
#0  wait_reading_process_output (time_limit=5, nsecs=0, read_kbd=0, 
    do_display=false, wait_for_cell=16374659, wait_proc=0x0, just_wait_proc=0)
    at process.c:5296
#1  0x00000000005b297d in x_get_foreign_selection (selection_symbol=9120, 
    target_type=240, time_stamp=0, frame=22101045) at xselect.c:1201
#2  0x00000000005b1f4c in Fx_get_selection_internal (selection_symbol=9120, 
    target_type=240, time_stamp=0, terminal=0) at xselect.c:2010
#3  0x00000000006fabf7 in funcall_subr (subr=0xbc8318, numargs=4, 
    args=0x7f7ffffdacd0) at eval.c:2849
#4  0x00000000006f983a in Ffuncall (nargs=5, args=0x7f7ffffdacc8)
    at eval.c:2766
#5  0x0000000000782f3d in exec_byte_code (bytestr=26624420, vector=20306061, 
    maxdepth=38, args_template=4106, nargs=2, args=0x7f7ffffdb798)
    at bytecode.c:629
#6  0x00000000006fafc5 in funcall_lambda (fun=23387365, nargs=2, 
    arg_vector=0x7f7ffffdb788) at eval.c:2967
#7  0x00000000006f9882 in Ffuncall (nargs=3, args=0x7f7ffffdb780)
    at eval.c:2768
#8  0x00000000006f961a in Fapply (nargs=2, args=0x7f7ffffdc0f0) at eval.c:2386
#9  0x00000000006faa86 in funcall_subr (subr=0xed78d8, numargs=2, 
    args=0x7f7ffffdc0f0) at eval.c:2821
#10 0x00000000006f983a in Ffuncall (nargs=3, args=0x7f7ffffdc0e8)
    at eval.c:2766
#11 0x0000000000782f3d in exec_byte_code (bytestr=22680196, vector=21880661, 
    maxdepth=62, args_template=514, nargs=2, args=0x7f7ffffdcc20)
    at bytecode.c:629
#12 0x00000000006fafc5 in funcall_lambda (fun=21811109, nargs=2, 
    arg_vector=0x7f7ffffdcc20) at eval.c:2967
#13 0x00000000006f9882 in Ffuncall (nargs=3, args=0x7f7ffffdcc18)
    at eval.c:2768
#14 0x0000000000782f3d in exec_byte_code (bytestr=13593108, vector=13593141, 
    maxdepth=38, args_template=2050, nargs=2, args=0x7f7ffffdd758)
    at bytecode.c:629
#15 0x00000000006fafc5 in funcall_lambda (fun=13593061, nargs=2, 
    arg_vector=0x7f7ffffdd748) at eval.c:2967
#16 0x00000000006f9882 in Ffuncall (nargs=3, args=0x7f7ffffdd740)
    at eval.c:2768
#17 0x0000000000782f3d in exec_byte_code (bytestr=11746807908, 
    vector=24821037, maxdepth=34, args_template=1030, nargs=1, 
    args=0x7f7ffffde348) at bytecode.c:629
#18 0x00000000006fafc5 in funcall_lambda (fun=24821173, nargs=1, 
    arg_vector=0x7f7ffffde340) at eval.c:2967
#19 0x00000000006f9882 in Ffuncall (nargs=2, args=0x7f7ffffde338)
    at eval.c:2768
#20 0x0000000000782f3d in exec_byte_code (bytestr=11743124740, 
    vector=11965495141, maxdepth=178, args_template=3074, nargs=0, 
    args=0x7f7ffffdf3e0) at bytecode.c:629
#21 0x00000000006fafc5 in funcall_lambda (fun=11965496357, nargs=0, 
    arg_vector=0x7f7ffffdf3e0) at eval.c:2967
#22 0x00000000006f9882 in Ffuncall (nargs=1, args=0x7f7ffffdf3d8)
    at eval.c:2768
#23 0x0000000000782f3d in exec_byte_code (bytestr=11904366884, 
    vector=9575961797, maxdepth=86, args_template=2050, nargs=1, 
    args=0x7f7ffffe01f8) at bytecode.c:629
#24 0x00000000006fafc5 in funcall_lambda (fun=9575962493, nargs=1, 
    arg_vector=0x7f7ffffe01f0) at eval.c:2967
#25 0x00000000006f9882 in Ffuncall (nargs=2, args=0x7f7ffffe01e8)
    at eval.c:2768
#26 0x00000000006daa3a in Ffuncall_interactively (nargs=2, args=0x7f7ffffe01e8)
    at callint.c:252
#27 0x00000000006faa86 in funcall_subr (subr=0xed7308, numargs=2, 
    args=0x7f7ffffe01e8) at eval.c:2821
#28 0x00000000006f983a in Ffuncall (nargs=3, args=0x7f7ffffe01e0)
    at eval.c:2766
#29 0x00000000006dd2bb in Fcall_interactively (function=7336368, 
    record_flag=0, keys=10242735877) at callint.c:841
#30 0x00000000006fabb9 in funcall_subr (subr=0xed72d8, numargs=3, 
    args=0x7f7ffffe0a20) at eval.c:2846
#31 0x00000000006f983a in Ffuncall (nargs=4, args=0x7f7ffffe0a18)
    at eval.c:2766
#32 0x0000000000782f3d in exec_byte_code (bytestr=13161172, vector=13161205, 
    maxdepth=54, args_template=4102, nargs=1, args=0x7f7ffffe15a8)
    at bytecode.c:629
#33 0x00000000006fafc5 in funcall_lambda (fun=13161125, nargs=1, 
    arg_vector=0x7f7ffffe15a0) at eval.c:2967
#34 0x00000000006f9882 in Ffuncall (nargs=2, args=0x7f7ffffe1598)
    at eval.c:2768
#35 0x00000000006fa3b2 in call1 (fn=15840, arg1=7336368) at eval.c:2617
#36 0x00000000005d67d7 in command_loop_1 () at keyboard.c:1482
#37 0x00000000006eaa57 in internal_condition_case (
    bfun=0x5d5e50 <command_loop_1>, handlers=20688, hfun=0x5ec220 <cmd_error>)
    at eval.c:1332
#38 0x00000000005ec122 in command_loop_2 (ignore=0) at keyboard.c:1110
#39 0x00000000006ea218 in internal_catch (tag=50256, 
    func=0x5ec0f0 <command_loop_2>, arg=0) at eval.c:1097
#40 0x00000000005d5414 in command_loop () at keyboard.c:1089
#41 0x00000000005d527c in recursive_edit_1 () at keyboard.c:695
#42 0x00000000005d559e in Frecursive_edit () at keyboard.c:766
#43 0x00000000005d301f in main (argc=1, argv=0x7f7ffffe1d78) at emacs.c:1713

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Manuel Giraud]

Hi,

Here is a patch against HEAD to avoid the hang in infinite loop. The
'x-selection-timeout' pause will still be there even with this patch.

My understandings:

On OpenBSD, most of the time, the function
"xselect.c/x_get_foreign_selection" won't get a SelectNotify with
(SECONDARY, TEXT) as arguments (that I did not understand and it might
never happen on other oses).

But then, while waiting at most 'x-selection-timeout' into
"process.c/wait_reading_process_output" the 'now' variable won't have a
chance of being invalidated or updated and that is what cause the
infinite loop.

Someone more knowledgeable of "process.c/wait_reading_process_output"
might have a better solution to this problem.

diff --git a/src/process.c b/src/process.c
index fc46e74332..25bd28a82b 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5115,8 +5115,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
       /* Exit if already run out.  */
       if (wait == TIMEOUT)
 	{
-	  if (!timespec_valid_p (now))
-	    now = current_timespec ();
+	  now = current_timespec ();
 	  if (timespec_cmp (end_time, now) <= 0)
 	    break;
 	  timeout = timespec_sub (end_time, now);
-- 
Manuel Giraud

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Grégoire Jadi]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Hi,

Hello Manuel,

Thanks for the reply and sorry for the delay.

> Here is a patch against HEAD to avoid the hang in infinite loop. The
> 'x-selection-timeout' pause will still be there even with this patch.

I've tested your patch on emacs-25-3.1 and it does prevent the infinite
loop. However, if the user sends input to emacs while it is waiting, it
raises the following backtrace :

Debugger entered--Lisp error: (error "Timed out waiting for reply from selection owner")
  x-get-selection-internal(SECONDARY STRING nil nil)
  #[1026 "\300\x04$\207" [x-get-selection-internal] 9 "\n\n(fn SELECTION-SYMBOL TARGET-TYPE &optional TIME-STAMP TERMINAL)"](SECONDARY STRING)
  apply(#[1026 "\300\x04$\207" [x-get-selection-internal] 9 "\n\n(fn SELECTION-SYMBOL TARGET-TYPE &optional TIME-STAMP TERMINAL)"] (SECONDARY STRING))
  gui-backend-get-selection(SECONDARY STRING)
  gui-get-selection(SECONDARY STRING)
  (let ((value (quote SECONDARY)) (x-selection-timeout 2000)) (gui-get-selection value (quote UTF8_STRING)) (gui-get-selection value (quote COMPOUND_TEXT)) (gui-get-selection value (quote STRING)) (gui-get-selection value (quote TEXT)))
  eval((let ((value (quote SECONDARY)) (x-selection-timeout 2000)) (gui-get-selection value (quote UTF8_STRING)) (gui-get-selection value (quote COMPOUND_TEXT)) (gui-get-selection value (quote STRING)) (gui-get-selection value (quote TEXT))) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

But it's still better than a complete freeze IMO.

> My understandings:
>
> On OpenBSD, most of the time, the function
> "xselect.c/x_get_foreign_selection" won't get a SelectNotify with
> (SECONDARY, TEXT) as arguments (that I did not understand and it might
> never happen on other oses).
>
> But then, while waiting at most 'x-selection-timeout' into
> "process.c/wait_reading_process_output" the 'now' variable won't have a
> chance of being invalidated or updated and that is what cause the
> infinite loop.
>
> Someone more knowledgeable of "process.c/wait_reading_process_output"
> might have a better solution to this problem.
>
> diff --git a/src/process.c b/src/process.c
> index fc46e74332..25bd28a82b 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5115,8 +5115,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>        /* Exit if already run out.  */
>        if (wait == TIMEOUT)
>  	{
> -	  if (!timespec_valid_p (now))
> -	    now = current_timespec ();
> +	  now = current_timespec ();
>  	  if (timespec_cmp (end_time, now) <= 0)
>  	    break;
>  	  timeout = timespec_sub (end_time, now);

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Manuel Giraud]

daimrod@omecha.info (Grégoire Jadi) writes:

> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
>> Hi,
>
> Hello Manuel,
>
> Thanks for the reply and sorry for the delay.

Same :-)

>> Here is a patch against HEAD to avoid the hang in infinite loop. The
>> 'x-selection-timeout' pause will still be there even with this patch.
>
> I've tested your patch on emacs-25-3.1 and it does prevent the infinite
> loop. However, if the user sends input to emacs while it is waiting, it
> raises the following backtrace :

Ok. There seems to be ongoing work on wait_reading_process_output:
https://lists.gnu.org/archive/html/emacs-devel/2017-11/threads.html#00037

So it might be urgent to wait and see what happens on OpenBSD after this
work is done. What you think?
-- 
Manuel Giraud

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Grégoire Jadi]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> daimrod@omecha.info (Grégoire Jadi) writes:
>
>> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>>
>>> Hi,
>>
>> Hello Manuel,
>>
>> Thanks for the reply and sorry for the delay.
>
> Same :-)
>
>>> Here is a patch against HEAD to avoid the hang in infinite loop. The
>>> 'x-selection-timeout' pause will still be there even with this patch.
>>
>> I've tested your patch on emacs-25-3.1 and it does prevent the infinite
>> loop. However, if the user sends input to emacs while it is waiting, it
>> raises the following backtrace :
>
> Ok. There seems to be ongoing work on wait_reading_process_output:
> https://lists.gnu.org/archive/html/emacs-devel/2017-11/threads.html#00037
>
> So it might be urgent to wait and see what happens on OpenBSD after this
> work is done. What you think?

I agree with you. I saw this discussion too, though I don't understand
most of it. I blindly tried the patches to see if it fixed the problem
but it did not.

Maybe someone will look at this bug once its merged.
So, let's wait :)

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Manuel Giraud]

daimrod@omecha.info (Grégoire Jadi) writes:

> I agree with you. I saw this discussion too, though I don't understand
> most of it. I blindly tried the patches to see if it fixed the problem
> but it did not.

I've just tried it too and get to the same conclusion :-)
-- 
Manuel Giraud

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Stefan Kangas]

[Accidentally sent off-list, forwarding message to bug tracker.]

-------------------- Start of forwarded message --------------------
From: Manuel Giraud <manuel@ledu-giraud.fr>
To: Stefan Kangas <stefan@marxist.se>
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Mon, 24 Aug 2020 13:25:39 +0200

Stefan Kangas <stefan@marxist.se> writes:

> That was almost 3 years ago.  Is this still an issue on recent versions
> of Emacs?

Hi Stefan,

I've just tested with an almost -current OpenBSD and a bleeding edge
emacs (bc5da2c3fb882a2d) and this issue still stand.

For my usage, it shows mostly when using org-capture. There is some kind
of fix (I think it is documented in this bug report) that is to set
Emacs*selectionTimeout resource to a lower value (e.g. 10).

Best regards,
-- 
Manuel Giraud
-------------------- End of forwarded message --------------------

bug#29170: Infinite loop noticed on Emacs in OpenBSD

[Stefan Kangas]

[Accidentally sent off-list, forwarding message to bug tracker.]

-------------------- Start of forwarded message --------------------
From: Stefan Kangas <stefan@marxist.se>
To: Manuel Giraud <manuel@ledu-giraud.fr>
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Mon, 10 Aug 2020 09:25:29 -0700

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Hi,
>
> Here is a patch against HEAD to avoid the hang in infinite loop. The
> 'x-selection-timeout' pause will still be there even with this patch.
>
> My understandings:
>
> On OpenBSD, most of the time, the function
> "xselect.c/x_get_foreign_selection" won't get a SelectNotify with
> (SECONDARY, TEXT) as arguments (that I did not understand and it might
> never happen on other oses).
>
> But then, while waiting at most 'x-selection-timeout' into
> "process.c/wait_reading_process_output" the 'now' variable won't have a
> chance of being invalidated or updated and that is what cause the
> infinite loop.
>
> Someone more knowledgeable of "process.c/wait_reading_process_output"
> might have a better solution to this problem.
>
> diff --git a/src/process.c b/src/process.c
> index fc46e74332..25bd28a82b 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5115,8 +5115,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>        /* Exit if already run out.  */
>        if (wait == TIMEOUT)
>  	{
> -	  if (!timespec_valid_p (now))
> -	    now = current_timespec ();
> +	  now = current_timespec ();
>  	  if (timespec_cmp (end_time, now) <= 0)
>  	    break;
>  	  timeout = timespec_sub (end_time, now);

That was almost 3 years ago.  Is this still an issue on recent versions
of Emacs?

Best regards,
Stefan Kangas
-------------------- End of forwarded message --------------------

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Lars Ingebrigtsen]

daimrod@omecha.info (Grégoire Jadi) writes:

> For some time now (emacs-25.1), emacs freezes when I use `org-capture'.
> The problem occurs when emacs tries to read the SECONDARY selection.
>
> The following snippet can be used to freeze emacs for 2s everytime on my
> computer :
> (let ((value 'SECONDARY)
>       (x-selection-timeout 2000))
>   ;;; from org-get-x-clipboard in lisp/org-compat.el
>   (gui-get-selection value 'UTF8_STRING)
>   (gui-get-selection value 'COMPOUND_TEXT)
>   (gui-get-selection value 'STRING)
>   (gui-get-selection value 'TEXT))
>
> If the user (me) send any commands (C-p, C-n, M-x, ...) to emacs when it
> is frozen, Emacs will stay frozen even after the 2s timeout.

I tried this recipe now on OpenBSD with Emacs 28, and I can confirm that
this freezes Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 02 Oct 2020 07:16:57 +0200
> Cc: 29170@debbugs.gnu.org
> 
> daimrod@omecha.info (Grégoire Jadi) writes:
> 
> > For some time now (emacs-25.1), emacs freezes when I use `org-capture'.
> > The problem occurs when emacs tries to read the SECONDARY selection.
> >
> > The following snippet can be used to freeze emacs for 2s everytime on my
> > computer :
> > (let ((value 'SECONDARY)
> >       (x-selection-timeout 2000))
> >   ;;; from org-get-x-clipboard in lisp/org-compat.el
> >   (gui-get-selection value 'UTF8_STRING)
> >   (gui-get-selection value 'COMPOUND_TEXT)
> >   (gui-get-selection value 'STRING)
> >   (gui-get-selection value 'TEXT))
> >
> > If the user (me) send any commands (C-p, C-n, M-x, ...) to emacs when it
> > is frozen, Emacs will stay frozen even after the 2s timeout.
> 
> I tried this recipe now on OpenBSD with Emacs 28, and I can confirm that
> this freezes Emacs.

Can you debug the cause which causes the freeze?  What is the code
that freezes?

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you debug the cause which causes the freeze?  What is the code
> that freezes?

I haven't debugged it, but Manuel said previously in this thread that
the following patch sort of fixes the problem (included below), but it
then leads to other issues.

But the problem is in that area, I take it.

-----

Here is a patch against HEAD to avoid the hang in infinite loop. The
'x-selection-timeout' pause will still be there even with this patch.

My understandings:

On OpenBSD, most of the time, the function
"xselect.c/x_get_foreign_selection" won't get a SelectNotify with
(SECONDARY, TEXT) as arguments (that I did not understand and it might
never happen on other oses).

But then, while waiting at most 'x-selection-timeout' into
"process.c/wait_reading_process_output" the 'now' variable won't have a
chance of being invalidated or updated and that is what cause the
infinite loop.

Someone more knowledgeable of "process.c/wait_reading_process_output"
might have a better solution to this problem.

diff --git a/src/process.c b/src/process.c
index fc46e74332..25bd28a82b 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5115,8 +5115,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
       /* Exit if already run out.  */
       if (wait == TIMEOUT)
 	{
-	  if (!timespec_valid_p (now))
-	    now = current_timespec ();
+	  now = current_timespec ();
 	  if (timespec_cmp (end_time, now) <= 0)
 	    break;
 	  timeout = timespec_sub (end_time, now);


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: daimrod@omecha.info,  29170@debbugs.gnu.org
> Date: Fri, 02 Oct 2020 16:30:45 +0200
> 
> On OpenBSD, most of the time, the function
> "xselect.c/x_get_foreign_selection" won't get a SelectNotify with
> (SECONDARY, TEXT) as arguments (that I did not understand and it might
> never happen on other oses).
> 
> But then, while waiting at most 'x-selection-timeout' into
> "process.c/wait_reading_process_output" the 'now' variable won't have a
> chance of being invalidated or updated and that is what cause the
> infinite loop.
> 
> Someone more knowledgeable of "process.c/wait_reading_process_output"
> might have a better solution to this problem.

If this is an OpenBSD-only problem, maybe we should install that
change #ifdef'ed by OpenBSD?

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[daimrod]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: daimrod@omecha.info,  29170@debbugs.gnu.org
>> Date: Fri, 02 Oct 2020 16:30:45 +0200
>> 
>> On OpenBSD, most of the time, the function
>> "xselect.c/x_get_foreign_selection" won't get a SelectNotify with
>> (SECONDARY, TEXT) as arguments (that I did not understand and it might
>> never happen on other oses).
>> 
>> But then, while waiting at most 'x-selection-timeout' into
>> "process.c/wait_reading_process_output" the 'now' variable won't have a
>> chance of being invalidated or updated and that is what cause the
>> infinite loop.
>> 
>> Someone more knowledgeable of "process.c/wait_reading_process_output"
>> might have a better solution to this problem.
>
> If this is an OpenBSD-only problem, maybe we should install that
> change #ifdef'ed by OpenBSD?

I'll have to test it, but I've been told that the issue doesn't occur
when the "junk" is disabled in the memory allocator (j = 0).

See MALLOC OPTIONS in malloc(3) https://man.openbsd.org/malloc

j       “Less junking”.  Decrease the junk level by one if it is larger
        than 0.  Junking writes some junk bytes into the area allocated.
        Junk is bytes of 0xdb when allocating; freed chunks are filled
        with 0xdf.  By default the junk level is 1: after free, small
        chunks are completely junked; for pages the first part is junked.
        After a delay, the filling pattern is validated and the process
        is aborted if the pattern was modified.  For junk level 2,
        junking is done on allocation as well and without size
        restrictions.  If the junk level is zero, no junking is
        performed.

-- 
gjadi
PGP : AF26 E9C2 A1C8 8D32 A868  4386 1373 5477 2B65 1894

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Lars Ingebrigtsen]

daimrod@omecha.info writes:

>> If this is an OpenBSD-only problem, maybe we should install that
>> change #ifdef'ed by OpenBSD?

Yes, but as noted by others in the thread, the patch leads to other
issues on OpenBSD, too, so it's not a complete solution.

> I'll have to test it, but I've been told that the issue doesn't occur
> when the "junk" is disabled in the memory allocator (j = 0).
>
> See MALLOC OPTIONS in malloc(3) https://man.openbsd.org/malloc
>
> j       “Less junking”.  Decrease the junk level by one if it is larger
>         than 0.  Junking writes some junk bytes into the area allocated.
>         Junk is bytes of 0xdb when allocating; freed chunks are filled
>         with 0xdf.  By default the junk level is 1: after free, small
>         chunks are completely junked; for pages the first part is junked.
>         After a delay, the filling pattern is validated and the process
>         is aborted if the pattern was modified.  For junk level 2,
>         junking is done on allocation as well and without size
>         restrictions.  If the junk level is zero, no junking is
>         performed.

Huh.  How odd that this would have an affect on this infloop?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[daimrod]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> daimrod@omecha.info writes:
>
>>> If this is an OpenBSD-only problem, maybe we should install that
>>> change #ifdef'ed by OpenBSD?
>
> Yes, but as noted by others in the thread, the patch leads to other
> issues on OpenBSD, too, so it's not a complete solution.
>
>> I'll have to test it, but I've been told that the issue doesn't occur
>> when the "junk" is disabled in the memory allocator (j = 0).
>>
>> See MALLOC OPTIONS in malloc(3) https://man.openbsd.org/malloc
>>
>> j       “Less junking”.  Decrease the junk level by one if it is larger
>>         than 0.  Junking writes some junk bytes into the area allocated.
>>         Junk is bytes of 0xdb when allocating; freed chunks are filled
>>         with 0xdf.  By default the junk level is 1: after free, small
>>         chunks are completely junked; for pages the first part is junked.
>>         After a delay, the filling pattern is validated and the process
>>         is aborted if the pattern was modified.  For junk level 2,
>>         junking is done on allocation as well and without size
>>         restrictions.  If the junk level is zero, no junking is
>>         performed.
>
> Huh.  How odd that this would have an affect on this infloop?

So, I tested it on emacs-27.1 with junk disabled and it still freezes.

$ MALLOC_OPTIONS=jj emacs -q

(let ((value 'SECONDARY)
      (x-selection-timeout 2000))
  ;;; from org-get-x-clipboard in lisp/org-compat.el
  (gui-get-selection value 'UTF8_STRING)
  (gui-get-selection value 'COMPOUND_TEXT)
  (gui-get-selection value 'STRING)
  (gui-get-selection value 'TEXT))

-- 
daimrod
PGP : AF26 E9C2 A1C8 8D32 A868  4386 1373 5477 2B65 1894

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Lars Ingebrigtsen]

<daimrod@omecha.info> writes:

> So, I tested it on emacs-27.1 with junk disabled and it still freezes.
>
> $ MALLOC_OPTIONS=jj emacs -q
>
> (let ((value 'SECONDARY)
>       (x-selection-timeout 2000))
>   ;;; from org-get-x-clipboard in lisp/org-compat.el
>   (gui-get-selection value 'UTF8_STRING)
>   (gui-get-selection value 'COMPOUND_TEXT)
>   (gui-get-selection value 'STRING)
>   (gui-get-selection value 'TEXT))

Thanks for checking.  So it sounds like we do need something like the
proposed patch (with #ifdef OpenBSD) here, but apparently the patch led
to other problems.

> I've tested your patch on emacs-25-3.1 and it does prevent the infinite
> loop. However, if the user sends input to emacs while it is waiting, it
> raises the following backtrace :
>
> Debugger entered--Lisp error: (error "Timed out waiting for reply from
> selection owner")
>   x-get-selection-internal(SECONDARY STRING nil nil)

So further work is needed here.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Grégoire Jadi]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi,

We (jca@ in Cc is the OpenBSD's maintainer of emacs) finally found a
solution to this bug.  The issue is in the broken SIGIO management.

This option was enabled on OpenBSD in 2011 as a workaround but it is not
required anymore.  We have disabled emacs_broken_SIGIO in OpenBSD's
ports tree and received lots of positive feedbacks (no more hang, some
operations are faster).

So we think it is safe to backport this change upstream.

diff --git a/configure.ac b/configure.ac
index c924634d5b..740f6d79a1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4884,7 +4884,7 @@ AC_DEFUN
 
 case $opsys in
   dnl SIGIO exists, but the feature doesn't work in the way Emacs needs.
-  hpux* | nacl | openbsd | solaris | unixware )
+  hpux* | nacl | solaris | unixware )
     emacs_broken_SIGIO=yes
     ;;
 
Please note that the real issue is not fixed.  The issue is in the
broken SIGIO code itself.  I was able to reproduce the bug by enabling
emacs_broken_SIGIO on Ubuntu LTS 20.04.  I didn't take the time to find
a fix though.


Best,

> <daimrod@omecha.info> writes:
>
>> So, I tested it on emacs-27.1 with junk disabled and it still freezes.
>>
>> $ MALLOC_OPTIONS=jj emacs -q
>>
>> (let ((value 'SECONDARY)
>>       (x-selection-timeout 2000))
>>   ;;; from org-get-x-clipboard in lisp/org-compat.el
>>   (gui-get-selection value 'UTF8_STRING)
>>   (gui-get-selection value 'COMPOUND_TEXT)
>>   (gui-get-selection value 'STRING)
>>   (gui-get-selection value 'TEXT))
>
> Thanks for checking.  So it sounds like we do need something like the
> proposed patch (with #ifdef OpenBSD) here, but apparently the patch led
> to other problems.
>
>> I've tested your patch on emacs-25-3.1 and it does prevent the infinite
>> loop. However, if the user sends input to emacs while it is waiting, it
>> raises the following backtrace :
>>
>> Debugger entered--Lisp error: (error "Timed out waiting for reply from
>> selection owner")
>>   x-get-selection-internal(SECONDARY STRING nil nil)
>
> So further work is needed here.  

-- 
gjadi
PGP : AF26 E9C2 A1C8 8D32 A868  4386 1373 5477 2B65 1894

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Eli Zaretskii]

> From: Grégoire Jadi <gjadi@omecha.info>
> Cc: Eli Zaretskii <eliz@gnu.org>,  29170@debbugs.gnu.org, jca@wxcvbn.org
> Date: Sun, 08 Aug 2021 16:33:48 +0200
> 
> Please note that the real issue is not fixed.  The issue is in the
> broken SIGIO code itself.  I was able to reproduce the bug by enabling
> emacs_broken_SIGIO on Ubuntu LTS 20.04.  I didn't take the time to find
> a fix though.

There's no broken SIGIO code, AFAICT.  If the configure script detects
that SIGIO is broken, it doesn't define USABLE_SIGIO, and then the
code conditioned by USABLE_SIGIO is not used.

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Grégoire Jadi]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Grégoire Jadi <gjadi@omecha.info>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  29170@debbugs.gnu.org, jca@wxcvbn.org
>> Date: Sun, 08 Aug 2021 16:33:48 +0200
>> 
>> Please note that the real issue is not fixed.  The issue is in the
>> broken SIGIO code itself.  I was able to reproduce the bug by enabling
>> emacs_broken_SIGIO on Ubuntu LTS 20.04.  I didn't take the time to find
>> a fix though.
>
> There's no broken SIGIO code, AFAICT.  If the configure script detects
> that SIGIO is broken, it doesn't define USABLE_SIGIO, and then the
> code conditioned by USABLE_SIGIO is not used.

You're correct.  What I meant is that by disabling USABLE_SIGIO on
Ubuntu, I was able to reproduce the same freezes.  Hence, it is the
codepath used when USABLE_SIGIO is disabled that causes the issue.

Best,

-- 
gjadi
PGP : AF26 E9C2 A1C8 8D32 A868  4386 1373 5477 2B65 1894

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Lars Ingebrigtsen]

Grégoire Jadi <gjadi@omecha.info> writes:

> So we think it is safe to backport this change upstream.

[...]

>    dnl SIGIO exists, but the feature doesn't work in the way Emacs needs.
> -  hpux* | nacl | openbsd | solaris | unixware )
> +  hpux* | nacl | solaris | unixware )

Thanks; I've now applied this to Emacs 28.

> Please note that the real issue is not fixed.  The issue is in the
> broken SIGIO code itself.  I was able to reproduce the bug by enabling
> emacs_broken_SIGIO on Ubuntu LTS 20.04.  I didn't take the time to find
> a fix though.

The remaining operating systems that uses the broken_SIGIO code paths
are pretty obscure -- I guess Solaris is still used to some degree.

Hm, let's see...  I guess the code paths that are exercised are the ones
where USABLE_SIGIO is undefined?  Do you have a simple test case for
this (on Ubuntu, for instance)?  I think it might make sense to open a
new bug report for this.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Grégoire Jadi]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Grégoire Jadi <gjadi@omecha.info> writes:
>
>> So we think it is safe to backport this change upstream.
>
> [...]
>
>>    dnl SIGIO exists, but the feature doesn't work in the way Emacs needs.
>> -  hpux* | nacl | openbsd | solaris | unixware )
>> +  hpux* | nacl | solaris | unixware )
>
> Thanks; I've now applied this to Emacs 28.

Thanks !

>
>> Please note that the real issue is not fixed.  The issue is in the
>> broken SIGIO code itself.  I was able to reproduce the bug by enabling
>> emacs_broken_SIGIO on Ubuntu LTS 20.04.  I didn't take the time to find
>> a fix though.
>
> The remaining operating systems that uses the broken_SIGIO code paths
> are pretty obscure -- I guess Solaris is still used to some degree.
>
> Hm, let's see...  I guess the code paths that are exercised are the ones
> where USABLE_SIGIO is undefined?  Do you have a simple test case for
> this (on Ubuntu, for instance)?  I think it might make sense to open a
> new bug report for this.

Yes, the same snippet used to trigger the bug on OpenBSD can be used:

> (let ((value 'SECONDARY)
>       (x-selection-timeout 2000))
>   ;;; from org-get-x-clipboard in lisp/org-compat.el
>   (gui-get-selection value 'UTF8_STRING)
>   (gui-get-selection value 'COMPOUND_TEXT)
>   (gui-get-selection value 'STRING)
>   (gui-get-selection value 'TEXT))


Best regards,

-- 
gjadi
PGP : AF26 E9C2 A1C8 8D32 A868  4386 1373 5477 2B65 1894

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Lars Ingebrigtsen]

Grégoire Jadi <gjadi@omecha.info> writes:

>> Hm, let's see...  I guess the code paths that are exercised are the ones
>> where USABLE_SIGIO is undefined?  Do you have a simple test case for
>> this (on Ubuntu, for instance)?  I think it might make sense to open a
>> new bug report for this.
>
> Yes, the same snippet used to trigger the bug on OpenBSD can be used:
>
>> (let ((value 'SECONDARY)
>>       (x-selection-timeout 2000))
>>   ;;; from org-get-x-clipboard in lisp/org-compat.el
>>   (gui-get-selection value 'UTF8_STRING)
>>   (gui-get-selection value 'COMPOUND_TEXT)
>>   (gui-get-selection value 'STRING)
>>   (gui-get-selection value 'TEXT))

I tried the following on this Debian/bullseye system.  I changed the
following in src/config.h:

/* Define to 1 if SIGIO is usable. */
#define USABLE_SIGIO 0

and then I build Emacs and ran the snippet -- and it didn't hang for
me.  Are there additional steps necessary?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29170: 26.0.90; Emacs freezes when capturing an org-template

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> /* Define to 1 if SIGIO is usable. */
> #define USABLE_SIGIO 0

Oh, hang on -- the code checks whether it's defined, not that it's 1/0.

Yes, with USABLE_SIGIO undefined, I can reproduce the error.  So I'm
opening a new bug report for this.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#29170: bug29170

[graeme vetterlein]

In case it's of any help tracking this down.

I have never, previously, seen this behaviour in 30+ years or Emacs use.

I am running Buster. I recently switched from cinnamon to Xfce as 
desktop manager, the issue now appears about 10% of the time when I exit 
Emacs (e.g via closing the window using X decoration, or C-x C-c )

Message reads:

Saving clipboard to X clipboard manager...

An that Emacs session NEVER exits:

GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) of 
2021-01-31, modified by Debian

$ uname -a
Linux real 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 
GNU/Linux

$ cat /etc/*release*
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"--

$ cat /etc/*version*
10.9
cat: /etc/subversion: Is a directory




AFYI: the Emacs sessions are 100% (looks to be user) CPU  and Xorg is 
high on the iotop list


-- 

Graeme