GNU bug report logs - #29170
Emacs freezes when doing a gui-get-selection on OpenBSD

Previous Next

Package: emacs;

Reported by: daimrod <at> omecha.info (Grégoire Jadi)

Date: Mon, 6 Nov 2017 14:22:02 UTC

Severity: normal

Tags: confirmed

Merged with 45544

Found in versions 26.0.90, 27.1.90

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29170 in the body.
You can then email your comments to 29170 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Mon, 06 Nov 2017 14:22:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to daimrod <at> omecha.info (Grégoire Jadi):
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 06 Nov 2017 14:22:02 GMT) Full text and rfc822 format available.

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

From: daimrod <at> omecha.info (Grégoire Jadi)
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.90; Emacs freezes when capturing an org-template
Date: Mon, 06 Nov 2017 15:20:41 +0100
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Wed, 08 Nov 2017 18:22:03 GMT) Full text and rfc822 format available.

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

From: Piotr Isajew <pki <at> ex.com.pl>
To: 29170 <at> debbugs.gnu.org
Subject: Infinite loop noticed on Emacs in OpenBSD
Date: Wed, 8 Nov 2017 19:00:42 +0100
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Thu, 09 Nov 2017 15:07:01 GMT) Full text and rfc822 format available.

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: 29170 <at> debbugs.gnu.org
Subject: Infinite loop noticed on Emacs in OpenBSD
Date: Thu, 09 Nov 2017 16:06:22 +0100
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 17 Nov 2017 14:37:01 GMT) Full text and rfc822 format available.

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

From: daimrod <at> omecha.info (Grégoire Jadi)
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Fri, 17 Nov 2017 15:36:19 +0100
Manuel Giraud <manuel <at> 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$\207" [x-get-selection-internal] 9 "\n\n(fn SELECTION-SYMBOL TARGET-TYPE &optional TIME-STAMP TERMINAL)"](SECONDARY STRING)
  apply(#[1026 "\300$\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);




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Wed, 22 Nov 2017 14:45:02 GMT) Full text and rfc822 format available.

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: daimrod <at> omecha.info (Grégoire Jadi)
Cc: 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Wed, 22 Nov 2017 15:44:18 +0100
daimrod <at> omecha.info (Grégoire Jadi) writes:

> Manuel Giraud <manuel <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Wed, 22 Nov 2017 14:51:03 GMT) Full text and rfc822 format available.

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

From: daimrod <at> omecha.info (Grégoire Jadi)
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Wed, 22 Nov 2017 15:50:46 +0100
Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> daimrod <at> omecha.info (Grégoire Jadi) writes:
>
>> Manuel Giraud <manuel <at> 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 :)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Wed, 22 Nov 2017 15:01:01 GMT) Full text and rfc822 format available.

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: daimrod <at> omecha.info (Grégoire Jadi)
Cc: 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Wed, 22 Nov 2017 16:00:15 +0100
daimrod <at> 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




Changed bug title to 'Emacs freezes when capturing an org-template (multiple calls to gui-get-selection))' from '26.0.90; Emacs freezes when capturing an org-template' Request was from Noam Postavsky <npostavs <at> users.sourceforge.net> to control <at> debbugs.gnu.org. (Tue, 05 Dec 2017 13:48:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Mon, 24 Aug 2020 11:45:02 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Mon, 24 Aug 2020 07:43:57 -0400
[Accidentally sent off-list, forwarding message to bug tracker.]

-------------------- Start of forwarded message --------------------
From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Stefan Kangas <stefan <at> 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 <at> 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 --------------------




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Mon, 24 Aug 2020 11:46:01 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: Infinite loop noticed on Emacs in OpenBSD
Date: Mon, 24 Aug 2020 07:45:11 -0400
[Accidentally sent off-list, forwarding message to bug tracker.]

-------------------- Start of forwarded message --------------------
From: Stefan Kangas <stefan <at> marxist.se>
To: Manuel Giraud <manuel <at> 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 <at> 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 --------------------




Changed bug title to 'Emacs freezes when doing a gui-get-selection on OpenBSD' from 'Emacs freezes when capturing an org-template (multiple calls to gui-get-selection))' Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 02 Oct 2020 05:17:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 02 Oct 2020 05:18:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: daimrod <at> omecha.info (Grégoire Jadi)
Cc: 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 02 Oct 2020 07:16:57 +0200
daimrod <at> 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




Added tag(s) confirmed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 02 Oct 2020 05:18:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 02 Oct 2020 07:13:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: daimrod <at> omecha.info, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 02 Oct 2020 10:12:28 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 02 Oct 2020 07:16:57 +0200
> Cc: 29170 <at> debbugs.gnu.org
> 
> daimrod <at> 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?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 02 Oct 2020 14:31:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: daimrod <at> omecha.info, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 02 Oct 2020 16:30:45 +0200
Eli Zaretskii <eliz <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 02 Oct 2020 15:09:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: daimrod <at> omecha.info, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 02 Oct 2020 18:08:44 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: daimrod <at> omecha.info,  29170 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 02 Oct 2020 17:56:01 GMT) Full text and rfc822 format available.

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

From: daimrod <at> omecha.info
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 02 Oct 2020 19:55:29 +0200
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: daimrod <at> omecha.info,  29170 <at> 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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Sat, 03 Oct 2020 17:52:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: daimrod <at> omecha.info
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Sat, 03 Oct 2020 19:51:13 +0200
daimrod <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Thu, 08 Oct 2020 21:44:02 GMT) Full text and rfc822 format available.

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

From: <daimrod <at> omecha.info>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, daimrod <at> omecha.info, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Thu, 08 Oct 2020 23:43:28 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> daimrod <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Sat, 10 Oct 2020 19:58:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: <daimrod <at> omecha.info>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Sat, 10 Oct 2020 21:57:31 +0200
<daimrod <at> 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




Forcibly Merged 29170 45544. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 30 Dec 2020 03:31:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Tue, 25 May 2021 10:59:02 GMT) Full text and rfc822 format available.

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

From: graeme vetterlein <graeme.debian <at> vetterlein.com>
To: 29170 <at> debbugs.gnu.org
Subject: bug29170
Date: Tue, 25 May 2021 11:55:14 +0100
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Sun, 08 Aug 2021 14:50:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Grégoire Jadi <gjadi <at> omecha.info>
Cc: larsi <at> gnus.org, jca <at> wxcvbn.org, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Sun, 08 Aug 2021 17:49:03 +0300
> From: Grégoire Jadi <gjadi <at> omecha.info>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  29170 <at> debbugs.gnu.org, jca <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Sun, 08 Aug 2021 22:02:02 GMT) Full text and rfc822 format available.

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

From: Grégoire Jadi <gjadi <at> omecha.info>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jca <at> wxcvbn.org, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Sun, 08 Aug 2021 16:33:48 +0200
Lars Ingebrigtsen <larsi <at> 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 <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Sun, 08 Aug 2021 22:02:02 GMT) Full text and rfc822 format available.

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

From: Grégoire Jadi <gjadi <at> omecha.info>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, jca <at> wxcvbn.org, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Sun, 08 Aug 2021 16:53:53 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Grégoire Jadi <gjadi <at> omecha.info>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  29170 <at> debbugs.gnu.org, jca <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Mon, 09 Aug 2021 12:32:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Grégoire Jadi <gjadi <at> omecha.info>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jca <at> wxcvbn.org, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Mon, 09 Aug 2021 14:31:34 +0200
Grégoire Jadi <gjadi <at> 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 marked as fixed in version 28.1, send any further explanations to 29170 <at> debbugs.gnu.org and daimrod <at> omecha.info (Grégoire Jadi) Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 09 Aug 2021 12:32:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 13 Aug 2021 07:37:02 GMT) Full text and rfc822 format available.

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

From: Grégoire Jadi <gjadi <at> omecha.info>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jca <at> wxcvbn.org, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 13 Aug 2021 09:36:33 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Grégoire Jadi <gjadi <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 13 Aug 2021 11:52:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Grégoire Jadi <gjadi <at> omecha.info>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jca <at> wxcvbn.org, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 13 Aug 2021 13:50:43 +0200
Grégoire Jadi <gjadi <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29170; Package emacs. (Fri, 13 Aug 2021 11:53:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Grégoire Jadi <gjadi <at> omecha.info>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jca <at> wxcvbn.org, 29170 <at> debbugs.gnu.org
Subject: Re: bug#29170: 26.0.90; Emacs freezes when capturing an org-template
Date: Fri, 13 Aug 2021 13:52:18 +0200
Lars Ingebrigtsen <larsi <at> 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 archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 11 Sep 2021 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 200 days ago.

Previous Next


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