bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Daniel Clemente]

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

To reproduce bug#71176 I did a loop that constantly opens and closes new
frames, for e.g. 300 seconds:

for j in `seq 300`; do for i in `seq 10`; do urxvt -e emacsclient '-nw'
'-e' '(dired "~")' &; done; sleep 1 && killall emacsclient; done

I'm using TTY emacsclient (no X support).
The daemon was run with: emacs --fg-daemon -Q
I'm running inside gdb, and ignoring SIGPIPE with: handle SIGPIPE noprint
pass
The part in the command that opens dired isn't significant.


After 1.5 or 2 minutes running that for-loop, there's consistenly a stack
overflow.

Copying a comment from Eli from bug#71176:

> I think it's indeed a different issue -- if it is an issue at all:
> after all "Lisp nesting exceeds ‘max-lisp-eval-depth’" is not a crash,
> just a Lisp error, and it follows a use pattern that is, let's say,
> not very interesting.  What I see is that Emacs recursively calls
> functions that read from a client process, which most probably is
> called by the error recovery of server.el when you kill client frames.
> The error recovery code includes some wait functions that are intended
> to let the user see the error messages, and making that possible is
> much more important for us than avoiding Lisp nesting in scenarios
> like this one.


I also think this may not be an issue. Unless it affects something more
important.

The only argument I have to make opening+closing frames fast is that
otherwise this makes testing other bugs harder. For instance in bug#71176 I
needed to open+close frames for long periods of time, and I would prefer if
it's possible to do it for 5 minutes instead of seeing unrelated errors
after just 2 minutes.


While trying to reproduce this, I also found a SIGSEGV (see the next bug
report).
The fact that we have the stack overflow here means that reproducing the
SIGSEGV (in next bug report) is much harder, because we'll see the stack
overflow first.



process server <1083> no longer connected to pipe; closed it
process server <1084> no longer connected to pipe; closed it
process server <1085> no longer connected to pipe; closed it
process server <1086> no longer connected to pipe; closed it
process server <1092> no longer connected to pipe; closed it
process server <1093> no longer connected to pipe; closed it
process server <1094> no longer connected to pipe; closed it
process server <1095> no longer connected to pipe; closed it
process server <1096> no longer connected to pipe; closed it
Lisp nesting exceeds ‘max-lisp-eval-depth’: 1601
error in process sentinel: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process filter: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process sentinel: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process filter: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process sentinel: Lisp nesting exceeds `max-lisp-eval-depth': 1601
^Z
Program received signal SIGTSTP, Stopped (user).
pselect64_syscall (sigmask=0x0, timeout=<optimized out>, exceptfds=0x0,
writefds=0x7fffffaf69b0, readfds=0x7fffffaf6a30, nfds=11)
    at ../sysdeps/unix/sysv/linux/pselect.c:34
34 ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.

(gdb) xbacktrace
"sit-for" (0xffb4abf8)
"server-return-error" (0xffb4adc0)
"server-process-filter" (0xffb4b018)
"sit-for" (0xffb4d108)
"server-return-error" (0xffb4d2d0)
"server-process-filter" (0xffb4d528)
"sit-for" (0xffb4f618)
"server-return-error" (0xffb4f7e0)
"server-process-filter" (0xffb4fa38)
"sit-for" (0xffb51b28)
"server-return-error" (0xffb51cf0)
"server-process-filter" (0xffb51f48)
"sit-for" (0xffb54038)
"server-return-error" (0xffb54200)
"server-process-filter" (0xffb54458)
"sit-for" (0xffb56548)
"server-return-error" (0xffb56710)
"server-process-filter" (0xffb56968)
"sit-for" (0xffb58a58)
[…]

(gdb) bt
#0  pselect64_syscall (sigmask=0x0, timeout=<optimized out>, exceptfds=0x0,
writefds=0x7fffffaf69b0, readfds=0x7fffffaf6a30, nfds=11)
    at ../sysdeps/unix/sysv/linux/pselect.c:34
#1  __pselect (nfds=11, readfds=0x7fffffaf6a30, writefds=0x7fffffaf69b0,
exceptfds=0x0, timeout=<optimized out>, sigmask=0x0)
    at ../sysdeps/unix/sysv/linux/pselect.c:56
#2  0x00005555557de64a in really_call_select (arg=0x7fffffaf6770) at
thread.c:624
#3  0x00005555556ff527 in flush_stack_call_func1 (func=0x5555557de5b0
<really_call_select>, arg=0x7fffffaf6770) at alloc.c:5534
#4  0x00005555557dda67 in flush_stack_call_func (func=0x5555557de5b0
<really_call_select>, arg=0x7fffffaf6770) at /w/emacs/src/lisp.h:4507
#5  0x00005555557de705 in thread_select (func=0x7ffff551d980 <__pselect>,
max_fds=11, rfds=0x7fffffaf6a30, wfds=0x7fffffaf69b0, efds=0x0,
    timeout=0x7fffffaf6990, sigmask=0x0) at thread.c:656
#6  0x00005555557a8c3c in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5752
#7  0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#8  0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff0061a33)) at process.c:7619
#9  0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff0061a53), handlers=XIL(0x90),
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#10 0x00005555557ace83 in exec_sentinel (proc=XIL(0x55555769ec95),
reason=XIL(0x555557117d74)) at process.c:7669
#11 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#12 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#13 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#14 0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff0084a43)) at process.c:7619
#15 0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff0084a63), handlers=XIL(0x90),
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#16 0x00005555557ace83 in exec_sentinel (proc=XIL(0x555557889d1d),
reason=XIL(0x555557090bd4)) at process.c:7669
#17 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#18 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#19 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#20 0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff0085703)) at process.c:7619
#21 0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff0085723), handlers=XIL(0x90),
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#22 0x00005555557ace83 in exec_sentinel (proc=XIL(0x55555788a02d),
reason=XIL(0x55555708d514)) at process.c:7669
#23 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#24 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#25 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#26 0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff0085db3)) at process.c:7619
#27 0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff0085dd3), handlers=XIL(0x90),
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#28 0x00005555557ace83 in exec_sentinel (proc=XIL(0x55555788a1b5),
reason=XIL(0x55555708cf84)) at process.c:7669
#29 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#30 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#31 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#32 0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff0086443)) at process.c:7619
#33 0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff0086463), handlers=XIL(0x90),
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#34 0x00005555557ace83 in exec_sentinel (proc=XIL(0x55555788a33d),
reason=XIL(0x55555708cb54)) at process.c:7669
#35 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#36 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#37 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#38 0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff0086bb3)) at process.c:7619
#39 0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff0086bd3), handlers=XIL(0x90),
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#40 0x00005555557ace83 in exec_sentinel (proc=XIL(0x55555788a4c5),
reason=XIL(0x55555708c744)) at process.c:7669
#41 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#42 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#43 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#44 0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff0087423)) at process.c:7619
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb)




In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu) of 2024-05-26 built on
sonn
Repository revision: 74b8043e60dde6710d0ba413278c2cb36a84f8f2
Repository branch: master
System Description: Devuan GNU/Linux 5 (daedalus)

Configured using:
 'configure --prefix=/opt/dc/emacs/ --without-dbus --with-tiff=no
--without-tiff
 --without-libsystemd --without-dbus --with-mailutils
--with-native-compilation --with-x-toolkit=no
 --without-imagemagick --without-xft --without-harfbuzz --without-freetype
--without-libotf
 --without-xwidgets --without-xpm --without-jpeg --without-gif
--without-png --without-webp
 --without-rsvg --without-cairo --without-x 'CFLAGS=-g3 -O0''

Configured features:
GMP GNUTLS LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER SECCOMP SOUND SQLITE3
THREADS XIM ZLIB

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

Major mode: Lisp Interaction

Minor modes in effect:
  xterm-mouse-mode: t
  erc-track-mode: t
  erc-services-mode: t
  erc-ring-mode: t
  erc-netsplit-mode: t
  erc-menu-mode: t
  erc-match-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-readonly-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-autojoin-mode: t
  erc-networks-mode: t
  savehist-mode: t
  recentf-mode: t
  hexl-follow-ascii: t
  rainbow-delimiters-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  async-bytecomp-package-mode: t
  global-git-commit-mode: t
  jdecomp-mode: t
  projectile-mode: t
  global-semantic-decoration-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-show-unmatched-syntax-mode: -1
  semantic-mode: t
  rcirc-track-minor-mode: t
  jabber-activity-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  unpackaged/org-export-html-with-useful-ids-mode: t
  minibuffer-depth-indicate-mode: t
  global-so-long-mode: t
  display-time-mode: t
  global-hl-line-mode: t
  xclip-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  hs-minor-mode: t

Load-path shadows:
/w/helm/helm-files hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-files
/w/helm/helm-comint hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-comint
/w/helm/helm-elisp-package hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-elisp-package
/w/helm/helm-external hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-external
/w/helm/helm-easymenu hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-easymenu
/w/helm/helm-font hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-font
/w/helm/helm-imenu hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-imenu
/w/helm/helm-x-files hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-x-files
/w/helm/helm-regexp hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-regexp
/w/helm/helm-net hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-net
/w/helm/helm-ring hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-ring
/w/helm/helm-find hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-find
/w/helm/helm-misc hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-misc
/w/helm/helm-occur hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-occur
/w/helm/helm-sys hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-sys
/w/helm/helm-types hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-types
/w/helm/helm-elisp hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-elisp
/w/helm/helm-adaptive hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-adaptive
/w/helm/helm-shell hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-shell
/w/helm/helm-id-utils hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-id-utils
/w/helm/helm-bookmark hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-bookmark
/w/helm/helm-mode hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-mode
/w/helm/helm-eshell hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-eshell
/w/helm/helm-dabbrev hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-dabbrev
/w/helm/helm-grep hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-grep
/w/helm/helm-color hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-color
/w/helm/helm-help hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-help
/w/helm/helm-buffers hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-buffers
/w/helm/helm-locate hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-locate
/w/helm/helm-tags hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-tags
/w/helm/helm-autoloads hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-autoloads
/w/helm/helm-info hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-info
/w/helm/helm-semantic hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-semantic
/w/helm/helm-config hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-config
/w/helm/helm-command hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-command
/w/helm/helm-utils hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-utils
/w/helm/helm-eval hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-eval
/w/helm/helm-for-files hides
/home/dc/.emacs.d/elpa/helm-20191101.641/helm-for-files
/w/helm/helm-man hides /home/dc/.emacs.d/elpa/helm-20191101.641/helm-man
/w/helm/helm-multi-match hides
/home/dc/.emacs.d/elpa/helm-core-20191031.1931/helm-multi-match
/w/helm/helm-lib hides
/home/dc/.emacs.d/elpa/helm-core-20191031.1931/helm-lib
/w/helm/helm-source hides
/home/dc/.emacs.d/elpa/helm-core-20191031.1931/helm-source
/w/helm/helm hides /home/dc/.emacs.d/elpa/helm-core-20191031.1931/helm
/home/dc/.emacs.d/elpa/transient-20220717.1713/transient hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/transient
/w/org-mode/lisp/org-fold-core hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-fold-core
/w/org-mode/lisp/ob-haskell hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-haskell
/w/org-mode/lisp/org-plot hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-plot
/w/org-mode/lisp/ox-icalendar hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-icalendar
/w/org-mode/lisp/org-footnote hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-footnote
/w/org-mode/lisp/org-archive hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-archive
/w/org-mode/lisp/ob-exp hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-exp
/w/org-mode/lisp/ob-octave hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-octave
/w/org-mode/lisp/oc-natbib hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/oc-natbib
/w/org-mode/lisp/org-num hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-num
/w/org-mode/lisp/ob-processing hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-processing
/w/org-mode/lisp/org-mouse hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-mouse
/w/org-mode/lisp/ob-core hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-core
/w/org-mode/lisp/ob-awk hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-awk
/w/org-mode/lisp/org-table hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-table
/w/org-mode/lisp/org-lint hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-lint
/w/org-mode/lisp/oc-basic hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/oc-basic
/w/org-mode/lisp/ob-scheme hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-scheme
/w/org-mode/lisp/ox-latex hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-latex
/w/org-mode/lisp/org-loaddefs hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-loaddefs
/w/org-mode/lisp/ob-table hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-table
/w/org-mode/lisp/ob-shell hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-shell
/w/org-mode/lisp/org hides /opt/dc/emacs/share/emacs/30.0.50/lisp/org/org
/w/org-mode/lisp/ol-man hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-man
/w/org-mode/lisp/ol-rmail hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-rmail
/w/org-mode/lisp/ox-man hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-man
/w/org-mode/lisp/org-cycle hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-cycle
/w/org-mode/lisp/org-datetree hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-datetree
/w/org-mode/lisp/ol-mhe hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-mhe
/w/org-mode/lisp/ob-css hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-css
/w/org-mode/lisp/org-fold hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-fold
/w/org-mode/lisp/ob-lilypond hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-lilypond
/w/org-mode/lisp/ob-comint hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-comint
/w/org-mode/lisp/ob-plantuml hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-plantuml
/w/org-mode/lisp/ol-bbdb hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-bbdb
/w/org-mode/lisp/ox-ascii hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-ascii
/w/org-mode/lisp/ob-python hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-python
/w/org-mode/lisp/ob-ref hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-ref
/w/org-mode/lisp/ob-js hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-js
/w/org-mode/lisp/ox-md hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-md
/w/org-mode/lisp/oc hides /opt/dc/emacs/share/emacs/30.0.50/lisp/org/oc
/w/org-mode/lisp/org-keys hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-keys
/w/org-mode/lisp/org-feed hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-feed
/w/org-mode/lisp/org-capture hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-capture
/w/org-mode/lisp/org-ctags hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-ctags
/w/org-mode/lisp/ob-lob hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-lob
/w/org-mode/lisp/ob-forth hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-forth
/w/org-mode/lisp/ob-clojure hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-clojure
/w/org-mode/lisp/ob-sass hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-sass
/w/org-mode/lisp/ol-eshell hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-eshell
/w/org-mode/lisp/org-timer hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-timer
/w/org-mode/lisp/ob-R hides /opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-R
/w/org-mode/lisp/org-src hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-src
/w/org-mode/lisp/ox-koma-letter hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-koma-letter
/w/org-mode/lisp/ob-tangle hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-tangle
/w/org-mode/lisp/ob-matlab hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-matlab
/w/org-mode/lisp/org-macro hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-macro
/w/org-mode/lisp/ob-makefile hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-makefile
/w/org-mode/lisp/ox-texinfo hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-texinfo
/w/org-mode/lisp/ob-org hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-org
/w/org-mode/lisp/ol-docview hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-docview
/w/org-mode/lisp/org-list hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-list
/w/org-mode/lisp/ob-eval hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-eval
/w/org-mode/lisp/org-element hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-element
/w/org-mode/lisp/ob hides /opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob
/w/org-mode/lisp/ob-sqlite hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-sqlite
/w/org-mode/lisp/org-clock hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-clock
/w/org-mode/lisp/org-compat hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-compat
/w/org-mode/lisp/org-mobile hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-mobile
/w/org-mode/lisp/ol hides /opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol
/w/org-mode/lisp/ob-groovy hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-groovy
/w/org-mode/lisp/org-goto hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-goto
/w/org-mode/lisp/ob-emacs-lisp hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-emacs-lisp
/w/org-mode/lisp/ol-eww hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-eww
/w/org-mode/lisp/org-tempo hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-tempo
/w/org-mode/lisp/oc-csl hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/oc-csl
/w/org-mode/lisp/ob-ruby hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-ruby
/w/org-mode/lisp/org-crypt hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-crypt
/w/org-mode/lisp/ol-irc hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-irc
/w/org-mode/lisp/org-faces hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-faces
/w/org-mode/lisp/ob-latex hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-latex
/w/org-mode/lisp/org-colview hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-colview
/w/org-mode/lisp/ol-bibtex hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-bibtex
/w/org-mode/lisp/ob-lua hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-lua
/w/org-mode/lisp/org-protocol hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-protocol
/w/org-mode/lisp/org-attach-git hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-attach-git
/w/org-mode/lisp/ob-screen hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-screen
/w/org-mode/lisp/org-agenda hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-agenda
/w/org-mode/lisp/org-persist hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-persist
/w/org-mode/lisp/ob-sql hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-sql
/w/org-mode/lisp/ob-gnuplot hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-gnuplot
/w/org-mode/lisp/ob-sed hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-sed
/w/org-mode/lisp/ol-gnus hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-gnus
/w/org-mode/lisp/org-inlinetask hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-inlinetask
/w/org-mode/lisp/ox-html hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-html
/w/org-mode/lisp/oc-biblatex hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/oc-biblatex
/w/org-mode/lisp/org-pcomplete hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-pcomplete
/w/org-mode/lisp/ob-perl hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-perl
/w/org-mode/lisp/org-version hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-version
/w/org-mode/lisp/org-indent hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-indent
/w/org-mode/lisp/org-refile hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-refile
/w/org-mode/lisp/ob-julia hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-julia
/w/org-mode/lisp/ol-info hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-info
/w/org-mode/lisp/ol-doi hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-doi
/w/org-mode/lisp/org-habit hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-habit
/w/org-mode/lisp/org-entities hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-entities
/w/org-mode/lisp/ox-publish hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-publish
/w/org-mode/lisp/org-duration hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-duration
/w/org-mode/lisp/ob-ditaa hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-ditaa
/w/org-mode/lisp/ob-dot hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-dot
/w/org-mode/lisp/ob-C hides /opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-C
/w/org-mode/lisp/ox-org hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-org
/w/org-mode/lisp/ox-beamer hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-beamer
/w/org-mode/lisp/ob-fortran hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-fortran
/w/org-mode/lisp/ob-maxima hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-maxima
/w/org-mode/lisp/ob-eshell hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-eshell
/w/org-mode/lisp/ol-w3m hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ol-w3m
/w/org-mode/lisp/org-id hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-id
/w/org-mode/lisp/ox-odt hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox-odt
/w/org-mode/lisp/ob-java hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-java
/w/org-mode/lisp/ob-calc hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-calc
/w/org-mode/lisp/org-attach hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-attach
/w/org-mode/lisp/ob-ocaml hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-ocaml
/w/org-mode/lisp/oc-bibtex hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/oc-bibtex
/w/org-mode/lisp/ox hides /opt/dc/emacs/share/emacs/30.0.50/lisp/org/ox
/w/org-mode/lisp/ob-lisp hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/ob-lisp
/w/org-mode/lisp/org-macs hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/org/org-macs
/w/flim/sasl hides /opt/dc/emacs/share/emacs/30.0.50/lisp/net/sasl
/home/dc/.emacs.d/elpa/hierarchy-20190425.842/hierarchy hides
/opt/dc/emacs/share/emacs/30.0.50/lisp/emacs-lisp/hierarchy

Features:
(shadow elmo-multi modb-standard elmo-maildir emacsbug winner tramp-archive
tramp-gvfs
xterm-keybinder xt-mouse term/rxvt term/xterm xterm hideshow ox-texinfo
erc-track erc-services
erc-ring erc-netsplit erc-menu erc-match erc-goodies erc-pcomplete
erc-button erc-fill erc-stamp
erc-join erc erc-backend erc-networks erc-common erc-compat erc-loaddefs
quail rot13 git-link
nukneval bustrofedon dired-filetype-face dired-tar gnus-dired dired-x
mime-w3m w3m-lnum w3m w3m-hist
bookmark-w3m w3m-ems w3m-favicon w3m-image w3m-fb tab-line w3m-proc
w3m-util savehist tramp-cache
time-stamp tramp-sh recentf tree-widget em-term term ehelp esh-ext esh-proc
esh-opt esh-io esh-arg
esh-module esh-groups esh-util zone-select zone org-location-google-maps
google-maps
google-maps-static google-maps-geocode google-maps-base beancount binview
calc calc-loaddefs
calc-macs hexl taskjuggler-mode generic generic-x boxquote rect
rainbow-delimiters rainbow-mode
htmlize-hack htmlize log4j-mode oddmuse skeleton doc-view jka-compr fc
flashcard-sm5 flashcard
keywiz gamegrid tt-mode helm-mode helm-misc helm-for-files helm-bookmark
helm-adaptive
magit-bookmark bookmark fringe helm-external helm-sys helm-net helm-man
helm-color helm-elisp
helm-files image-dired image-dired-tags image-dired-external
image-dired-util image-mode exif tramp
trampver tramp-integration files-x tramp-message tramp-compat
tramp-loaddefs helm-buffers helm-occur
helm-tags helm-locate helm-grep helm-regexp helm-info helm-utils helm-types
helm-eval edebug
helm-help helm helm-global-bindings helm-easymenu helm-core async-bytecomp
helm-source
helm-multi-match helm-lib async helm-config helm-autoloads diary-lib
diary-loaddefs magit-submodule
magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push
magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos
magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode
diff diff-mode track-changes
git-commit log-edit pcvs-util add-log magit-core magit-autorevert
autorevert filenotify magit-margin
magit-transient magit-process with-editor server magit-mode transient
magit-git magit-base
magit-section dash chuck-mode minizinc-mode jdecomp arc-mode archive-mode
cus-edit cus-load
projectile lisp-mnt ibuf-ext semantic/dep srecode/mode semantic/senator
semantic/wisent
semantic/wisent/wisent srecode/insert srecode/filters srecode/args
ede/speedbar ede/files ede
ede/detect ede/base ede/auto ede/source eieio-speedbar speedbar dframe
eieio-custom srecode/find
srecode/map srecode/ctxt srecode/compile srecode/dictionary srecode/fields
srecode/table
semantic/decorate/mode semantic/decorate pulse srecode semantic/db-mode
semantic/idle
semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn
semantic/db eieio-base
semantic/format ezimage semantic/tag-ls semantic/find semantic/ctxt
semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local
cedet rcirc offlineimap
sasl-xoauth2 oauth2 url-http url-auth url-gw nsm plstore crm wl-template
wl-fldmgr wl-score wl-demo
wl-thread wl-action wl wl-draft wl-folder elmo-nntp elmo-net elmo-cache
elmo-map elmo-dop ps-print
ps-print-loaddefs lpr elmo-filter wl-summary wl-refile wl-message wl-mime
mime-play filename
mime-edit mime-setup mail-mime-setup semi-setup smtp wl-e21 wl-highlight
invisible inv-23 elmo-mime
mmelmo-buffer mmelmo-imap mmimap mmbuffer mime-view mime-conf calist
semi-def wl-address pldap
wl-util wl-vars wl-version modb-generic elmo-flag elmo-localdir elmo
elmo-signal elmo-msgdb modb
modb-entity elmo-date eword-encode mime-parse mime mmgeneric elmo-util
eword-decode mel mime-def
alist pces pces-e20 pces-20 mcs-e20 mcs-20 mcharset timezone elmo-vars
path-util elmo-version luna
std11 pccl pccl-20 ccl broken static apel-ver product jabber
jabber-truncate jabber-time
jabber-autoaway jabber-vcard-avatars jabber-chatstates jabber-events
jabber-vcard jabber-avatar
jabber-activity jabber-watch jabber-modeline jabber-ahc-presence jabber-ahc
jabber-version
jabber-ourversion jabber-muc-nick-completion hippie-exp jabber-browse
jabber-search jabber-register
jabber-roster jabber-presence jabber-muc jabber-bookmarks jabber-private
jabber-muc-nick-coloring
jabber-widget jabber-disco jabber-chat jabber-history jabber-chatbuffer
jabber-alert jabber-iq
jabber-core jabber-console sgml-mode facemenu jabber-keymap jabber-sasl
sasl sasl-anonymous
sasl-login sasl-plain fsm jabber-logon jabber-conn srv dns starttls tls
jabber-xml jabber-menu
jabber-util goto-addr hexrgb markdown-mode color thingatpt yasnippet
org-contacts gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku
url-file svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo
parse-time iso8601 gnus-spec gnus-int gnus-range message sendmail
yank-media puny dired dnd
dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode
mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win gnus nnheader
mail-utils range mm-util mail-prsvr gnus-util org-crypt ob-sqlite ob-sql
ob-shell shell ob-ruby
ob-python python project compat ob-plantuml ob-perl ob-lilypond ob-js
ob-haskell ob-gnuplot ox-odt
rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse
nxml-ns nxml-enc xmltok
nxml-util ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox ob-dot
ob-ditaa ob-C cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs ob-R org-attach
org-protocol iimage org-clock calfw-gcal calfw-org org-capture org-agenda
calfw edmacro kmacro
holidays holiday-loaddefs cal-move org-inlinetask org-superstar org-element
org-persist xdg avl-tree
generator org-test ert-x ert pp ewoc debug backtrace org-id org-refile
org-element-ast inline org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src sh-script smie
treesit executable
ob-comint org-pcomplete pcomplete org-list org-footnote org-faces
org-entities time-date noutline
outline ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold
org-fold-core org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec
ibuf-macs ibuffer ibuffer-loaddefs mb-depth comp comp-cstr warnings
comp-run comp-common rx advice
mwheel easy-mmode so-long longlines grep compile text-property-search
comint regexp-opt ansi-osc
ansi-color ring revbufs derived disp-table hide-mode-line time image
hl-line color-theme wid-edit
reporter xclip finder-inf elp boxquote-autoloads calfw-autoloads
calfw-gcal-autoloads
calfw-ical-autoloads calfw-org-autoloads csv-mode-autoloads
debbugs-autoloads emacsql-psql-autoloads
emacsql-autoloads emmet-mode-autoloads feature-mode-autoloads
git-link-autoloads gnuplot-autoloads
google-translate-autoloads haskell-mode-autoloads cl-extra help-mode
helm-sql-connect-autoloads
jabber-autoloads fsm-autoloads jdecomp-autoloads jedi-autoloads
jedi-core-autoloads
jinja2-mode-autoloads json-reformat-autoloads jsonian-autoloads
magit-autoloads pcase
git-commit-autoloads magit-section-autoloads mingus-autoloads
libmpdee-autoloads
mmm-jinja2-autoloads mmm-mode-autoloads oauth2-autoloads
org-superstar-autoloads persist-autoloads
projectile-autoloads python-environment-autoloads rcirc-color-autoloads
srv-autoloads cl
terraform-mode-autoloads tmr-autoloads transient-autoloads
typescript-mode-autoloads
vimrc-mode-autoloads vue-html-mode-autoloads with-editor-autoloads
xclip-autoloads
xterm-keybinder-autoloads yasnippet-autoloads zone-nyan-autoloads info
tool-bar dash-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio
eieio-core cl-macs icons password-cache json subr-x map byte-opt gv
bytecomp byte-compile url-vars
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode tabulated-list replace newcomment text-mode
lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select mouse
jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj
charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray
oclosure cl-preloaded
button loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads
inotify lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 1145811 147437) (symbols 48 69097 0) (strings 32 271363 11419)
(string-bytes 1 9708056)
 (vectors 16 104712) (vector-slots 8 1200567 18616) (floats 8 1202 13512)
(intervals 56 1226 57)
 (buffers 984 14))

[-- Attachment #2: Type: text/html, Size: 38221 bytes --]

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Daniel Clemente <n142857@gmail.com>
> Date: Mon, 27 May 2024 11:01:15 +0000
> 
> (gdb) xbacktrace 
> "sit-for" (0xffb4abf8)
> "server-return-error" (0xffb4adc0)
> "server-process-filter" (0xffb4b018)
> "sit-for" (0xffb4d108)
> "server-return-error" (0xffb4d2d0)
> "server-process-filter" (0xffb4d528)
> "sit-for" (0xffb4f618)
> "server-return-error" (0xffb4f7e0)
> "server-process-filter" (0xffb4fa38)
> "sit-for" (0xffb51b28)
> "server-return-error" (0xffb51cf0)
> "server-process-filter" (0xffb51f48)
> "sit-for" (0xffb54038)
> "server-return-error" (0xffb54200)
> "server-process-filter" (0xffb54458)
> "sit-for" (0xffb56548)
> "server-return-error" (0xffb56710)
> "server-process-filter" (0xffb56968)
> "sit-for" (0xffb58a58)

Does the patch below help?

diff --git a/lisp/server.el b/lisp/server.el
index b650532..e89a205 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -1159,7 +1159,7 @@ server-process-filter
       ;; it, in case the error written by emacsclient to stderr is not
       ;; visible for some reason.
       (message "Authentication failed")
-      (sit-for 2)
+      (sit-for 2 t)
       (server-send-string
        proc (concat "-error " (server-quote-arg "Authentication failed")))
       (unless (eq system-type 'windows-nt)
@@ -1169,7 +1169,7 @@ server-process-filter
 	    (delete-terminal terminal))))
       ;; Before calling `delete-process', give emacsclient time to
       ;; receive the error string and shut down on its own.
-      (sit-for 1)
+      (sit-for 1 t)
       (delete-process proc)
       ;; We return immediately.
       (cl-return-from server-process-filter)))
@@ -1508,7 +1508,7 @@ server-return-error
     ;; it, in case the error written by emacsclient to stderr is not
     ;; visible for some reason.
     (message (error-message-string err))
-    (sit-for 2)
+    (sit-for 2 t)
     (server-send-string
      proc (concat "-error " (server-quote-arg
                              (error-message-string err))))
@@ -1520,7 +1520,7 @@ server-return-error
 	  (delete-terminal terminal))))
     ;; Before calling `delete-process', give emacsclient time to
     ;; receive the error string and shut down on its own.
-    (sit-for 5)
+    (sit-for 5 t)
     (delete-process proc)))
 
 (defun server-goto-line-column (line-col)

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> Cc: 71223@debbugs.gnu.org
> Date: Mon, 27 May 2024 15:23:01 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Does the patch below help?

Actually, the more thorough patch below should be better.  Can you see
if it solves the problems with "Lisp nesting exceeds
`max-lisp-eval-depth'"?

Stefan, any comments about the problem and the proposed solution?

diff --git a/lisp/server.el b/lisp/server.el
index b650532..fcaf0ab 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -1034,6 +1034,15 @@ server-goto-toplevel
     (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))
     (top-level)))
 
+(defun server--sit-for (proc seconds)
+  "Like `sit-for', but disable filter of process PROC and don't redisplay."
+  (let ((orig-filter (process-filter proc)))
+    (unwind-protect
+        (progn
+          (set-process-filter proc nil)
+          (sit-for seconds t))
+      (set-process-filter proc orig-filter))))
+
 ;; We use various special properties on process objects:
 ;; - `env' stores the info about the environment of the emacsclient process.
 ;; - `continuation' is a no-arg function that we need to execute.  It contains
@@ -1159,7 +1168,7 @@ server-process-filter
       ;; it, in case the error written by emacsclient to stderr is not
       ;; visible for some reason.
       (message "Authentication failed")
-      (sit-for 2)
+      (server--sit-for proc 2)
       (server-send-string
        proc (concat "-error " (server-quote-arg "Authentication failed")))
       (unless (eq system-type 'windows-nt)
@@ -1169,7 +1178,7 @@ server-process-filter
 	    (delete-terminal terminal))))
       ;; Before calling `delete-process', give emacsclient time to
       ;; receive the error string and shut down on its own.
-      (sit-for 1)
+      (server--sit-for proc 1)
       (delete-process proc)
       ;; We return immediately.
       (cl-return-from server-process-filter)))
@@ -1508,7 +1517,7 @@ server-return-error
     ;; it, in case the error written by emacsclient to stderr is not
     ;; visible for some reason.
     (message (error-message-string err))
-    (sit-for 2)
+    (server--sit-for proc 2)
     (server-send-string
      proc (concat "-error " (server-quote-arg
                              (error-message-string err))))
@@ -1520,7 +1529,7 @@ server-return-error
 	  (delete-terminal terminal))))
     ;; Before calling `delete-process', give emacsclient time to
     ;; receive the error string and shut down on its own.
-    (sit-for 5)
+    (server--sit-for proc 5)
     (delete-process proc)))
 
 (defun server-goto-line-column (line-col)

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> +(defun server--sit-for (proc seconds)
> +  "Like `sit-for', but disable filter of process PROC and don't redisplay."
> +  (let ((orig-filter (process-filter proc)))
> +    (unwind-protect
> +        (progn
> +          (set-process-filter proc nil)
> +          (sit-for seconds t))
> +      (set-process-filter proc orig-filter))))

Hmm... (set-process-filter proc nil) means that any process output will
be sent to the process's buffer rather than to the filter, which doesn't
sound right (it will make us miss that process output, basically).

If we want this to work well we need to store the process output we
receive during the `sit-for` and call the process filter in it afterwards.

Another option would be to offer a way to temporary suspend the
reception of process output for a specific process.  For most processes,
suspending reception of process output while running the process filter
would be the right thing to do, so even better would be to do that
automatically and offer instead a way for a process filter to explicitly
enable running itself recursively when/were it is needed.

>  ;; We use various special properties on process objects:
>  ;; - `env' stores the info about the environment of the emacsclient process.
>  ;; - `continuation' is a no-arg function that we need to execute.  It contains
> @@ -1159,7 +1168,7 @@ server-process-filter
>        ;; it, in case the error written by emacsclient to stderr is not
>        ;; visible for some reason.
>        (message "Authentication failed")
> -      (sit-for 2)
> +      (server--sit-for proc 2)
>        (server-send-string
>         proc (concat "-error " (server-quote-arg "Authentication failed")))
>        (unless (eq system-type 'windows-nt)

IIUC this `sit-for` is there to let the user see the message.
It's a common source of problems.

We should devise a variant of `message` which guarantees that the message
is shown for at least N seconds but without having to wait for the
N seconds to pass before running the rest of the code.

> @@ -1169,7 +1178,7 @@ server-process-filter
>  	    (delete-terminal terminal))))
>        ;; Before calling `delete-process', give emacsclient time to
>        ;; receive the error string and shut down on its own.
> -      (sit-for 1)
> +      (server--sit-for proc 1)
>        (delete-process proc)
>        ;; We return immediately.
>        (cl-return-from server-process-filter)))

I think a better option here is to run the `delete-process` from
a timer, so we can *really* return immediately.

> @@ -1508,7 +1517,7 @@ server-return-error
>      ;; it, in case the error written by emacsclient to stderr is not
>      ;; visible for some reason.
>      (message (error-message-string err))
> -    (sit-for 2)
> +    (server--sit-for proc 2)
>      (server-send-string
>       proc (concat "-error " (server-quote-arg
>                               (error-message-string err))))

Same as the first `sit-for` above.

> @@ -1520,7 +1529,7 @@ server-return-error
>  	  (delete-terminal terminal))))
>      ;; Before calling `delete-process', give emacsclient time to
>      ;; receive the error string and shut down on its own.
> -    (sit-for 5)
> +    (server--sit-for proc 5)
>      (delete-process proc)))

Same as the second `sit-for` above.


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Daniel Clemente]

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

I tried the patch, it still happens at the same point, and the stack is
~12k calls, like in previous tests.

process server <664> no longer connected to pipe; closed it
process server <665> no longer connected to pipe; closed it
error in process sentinel: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process sentinel: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process filter: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process filter: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process filter: Lisp nesting exceeds `max-lisp-eval-depth': 1601
error in process sentinel: Lisp nesting exceeds `max-lisp-eval-depth': 1601
[…]


(gdb) bt
#0  pselect64_syscall (sigmask=0x0, timeout=<optimized out>, exceptfds=0x0,
writefds=0x7fffffb95010, readfds=0x7fffffb95090, nfds=11)
    at ../sysdeps/unix/sysv/linux/pselect.c:34
#1  __pselect (nfds=11, readfds=0x7fffffb95090, writefds=0x7fffffb95010,
exceptfds=0x0, timeout=<optimized out>, sigmask=0x0)
    at ../sysdeps/unix/sysv/linux/pselect.c:56
#2  0x00005555557de64a in really_call_select (arg=0x7fffffb94dd0) at
thread.c:624
#3  0x00005555556ff527 in flush_stack_call_func1 (func=0x5555557de5b0
<really_call_select>, arg=0x7fffffb94dd0) at alloc.c:5534
#4  0x00005555557dda67 in flush_stack_call_func (func=0x5555557de5b0
<really_call_select>, arg=0x7fffffb94dd0) at /w/emacs/src/lisp.h:4507
#5  0x00005555557de705 in thread_select (func=0x7ffff551d980 <__pselect>,
max_fds=11, rfds=0x7fffffb95090, wfds=0x7fffffb95010, efds=0x0,
    timeout=0x7fffffb94ff0, sigmask=0x0) at thread.c:656
#6  0x00005555557a8c3c in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5752
--Type <RET> for more, q to quit, c to continue without paging--
#7  0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#8  0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff01db9d3)) at process.c:7619
#9  0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff01db9f3), handlers=XIL(0x90),
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#10 0x00005555557ace83 in exec_sentinel (proc=XIL(0x55555657d38d),
reason=XIL(0x5555565cf904)) at process.c:7669
#11 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#12 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#13 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
#14 0x00005555557accee in exec_sentinel_error_handler
(error_val=XIL(0x7ffff01dd203)) at process.c:7619
#15 0x0000555555732f74 in internal_condition_case_1 (bfun=0x5555557a9b01
<read_process_output_call>, arg=XIL(0x7ffff01dd223), handlers=XIL(0x90),
--Type <RET> for more, q to quit, c to continue without paging--
    hfun=0x5555557acc4d <exec_sentinel_error_handler>) at eval.c:1633
#16 0x00005555557ace83 in exec_sentinel (proc=XIL(0x5555567c3b65),
reason=XIL(0x555556506a54)) at process.c:7669
#17 0x00005555557ad103 in status_notify (deleting_process=0x0,
wait_proc=0x0) at process.c:7761
#18 0x00005555557a8399 in wait_reading_process_output (time_limit=1,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5493
#19 0x0000555555592512 in Fsleep_for (seconds=make_fixnum(1),
milliseconds=XIL(0)) at dispnew.c:6231
[…]

(gdb) xbacktrace
"sit-for" (0xffc518f8)
"server--sit-for" (0xffc51a88)
"server-return-error" (0xffc51c50)
"server-process-filter" (0xffc51ea8)
"sit-for" (0xffc53fa8)
"server--sit-for" (0xffc54138)
"server-return-error" (0xffc54300)
"server-process-filter" (0xffc54558)
"sit-for" (0xffc56658)
"server--sit-for" (0xffc567e8)
"server-return-error" (0xffc569b0)
[…]

On Mon, 27 May 2024 at 12:36, Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: 71223@debbugs.gnu.org
> > Date: Mon, 27 May 2024 15:23:01 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > Does the patch below help?
>
> Actually, the more thorough patch below should be better.  Can you see
> if it solves the problems with "Lisp nesting exceeds
> `max-lisp-eval-depth'"?
>
> Stefan, any comments about the problem and the proposed solution?
>
> diff --git a/lisp/server.el b/lisp/server.el
> index b650532..fcaf0ab 100644
> --- a/lisp/server.el
> +++ b/lisp/server.el
> @@ -1034,6 +1034,15 @@ server-goto-toplevel
>      (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))
>      (top-level)))
>
> +(defun server--sit-for (proc seconds)
> +  "Like `sit-for', but disable filter of process PROC and don't
> redisplay."
> +  (let ((orig-filter (process-filter proc)))
> +    (unwind-protect
> +        (progn
> +          (set-process-filter proc nil)
> +          (sit-for seconds t))
> +      (set-process-filter proc orig-filter))))
> +
>  ;; We use various special properties on process objects:
>  ;; - `env' stores the info about the environment of the emacsclient
> process.
>  ;; - `continuation' is a no-arg function that we need to execute.  It
> contains
> @@ -1159,7 +1168,7 @@ server-process-filter
>        ;; it, in case the error written by emacsclient to stderr is not
>        ;; visible for some reason.
>        (message "Authentication failed")
> -      (sit-for 2)
> +      (server--sit-for proc 2)
>        (server-send-string
>         proc (concat "-error " (server-quote-arg "Authentication failed")))
>        (unless (eq system-type 'windows-nt)
> @@ -1169,7 +1178,7 @@ server-process-filter
>             (delete-terminal terminal))))
>        ;; Before calling `delete-process', give emacsclient time to
>        ;; receive the error string and shut down on its own.
> -      (sit-for 1)
> +      (server--sit-for proc 1)
>        (delete-process proc)
>        ;; We return immediately.
>        (cl-return-from server-process-filter)))
> @@ -1508,7 +1517,7 @@ server-return-error
>      ;; it, in case the error written by emacsclient to stderr is not
>      ;; visible for some reason.
>      (message (error-message-string err))
> -    (sit-for 2)
> +    (server--sit-for proc 2)
>      (server-send-string
>       proc (concat "-error " (server-quote-arg
>                               (error-message-string err))))
> @@ -1520,7 +1529,7 @@ server-return-error
>           (delete-terminal terminal))))
>      ;; Before calling `delete-process', give emacsclient time to
>      ;; receive the error string and shut down on its own.
> -    (sit-for 5)
> +    (server--sit-for proc 5)
>      (delete-process proc)))
>
>  (defun server-goto-line-column (line-col)
>

[-- Attachment #2: Type: text/html, Size: 8151 bytes --]

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: n142857@gmail.com,  71223@debbugs.gnu.org
> Date: Mon, 27 May 2024 10:44:37 -0400
> 
> > +(defun server--sit-for (proc seconds)
> > +  "Like `sit-for', but disable filter of process PROC and don't redisplay."
> > +  (let ((orig-filter (process-filter proc)))
> > +    (unwind-protect
> > +        (progn
> > +          (set-process-filter proc nil)
> > +          (sit-for seconds t))
> > +      (set-process-filter proc orig-filter))))
> 
> Hmm... (set-process-filter proc nil) means that any process output will
> be sent to the process's buffer rather than to the filter, which doesn't
> sound right (it will make us miss that process output, basically).
> 
> If we want this to work well we need to store the process output we
> receive during the `sit-for` and call the process filter in it afterwards.

At this point we don't expect any output from the process, and if it
comes, don't want to know about it nor process it.  We are going to
shut down the client connection, so we are basically done with the
process.

Does this change your opinion on the patch?

> Another option would be to offer a way to temporary suspend the
> reception of process output for a specific process.  For most processes,
> suspending reception of process output while running the process filter
> would be the right thing to do, so even better would be to do that
> automatically and offer instead a way for a process filter to explicitly
> enable running itself recursively when/were it is needed.

The problem here is that the process filter calls sit-for, which reads
process output, which also calls the process filter, etc., etc. -- a
kind of infinite recursion.  If you looked at the backtraces provided
by the OP, you should see that very clearly:

> (gdb) xbacktrace 
> "sit-for" (0xffb4abf8)
> "server-return-error" (0xffb4adc0)
> "server-process-filter" (0xffb4b018)
> "sit-for" (0xffb4d108)
> "server-return-error" (0xffb4d2d0)
> "server-process-filter" (0xffb4d528)
> "sit-for" (0xffb4f618)
> "server-return-error" (0xffb4f7e0)
> "server-process-filter" (0xffb4fa38)
> "sit-for" (0xffb51b28)
> "server-return-error" (0xffb51cf0)
> "server-process-filter" (0xffb51f48)
> "sit-for" (0xffb54038)
> "server-return-error" (0xffb54200)
> "server-process-filter" (0xffb54458)
> "sit-for" (0xffb56548)
> "server-return-error" (0xffb56710)
> "server-process-filter" (0xffb56968)
> "sit-for" (0xffb58a58)

See?

> We should devise a variant of `message` which guarantees that the message
> is shown for at least N seconds but without having to wait for the
> N seconds to pass before running the rest of the code.

AFAIU, 'message' is not the problem, the problem is not to delete the
process object too quickly, because that causes all kinds of
unpleasant effects on the client side (see the bug reports related to
changes in these areas).

> I think a better option here is to run the `delete-process` from
> a timer, so we can *really* return immediately.

Then, in the scenario of this bug report, we could have large amounts
of processes we haven't chance to delete yet, because timers were not
run before the next connection starts.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Daniel Clemente <n142857@gmail.com>
> Date: Mon, 27 May 2024 15:21:02 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 71223@debbugs.gnu.org
> 
> I tried the patch, it still happens at the same point, and the stack is ~12k calls, like in previous tests.
> 
> (gdb) xbacktrace
> "sit-for" (0xffc518f8)
> "server--sit-for" (0xffc51a88)
> "server-return-error" (0xffc51c50)
> "server-process-filter" (0xffc51ea8)
> "sit-for" (0xffc53fa8)
> "server--sit-for" (0xffc54138)
> "server-return-error" (0xffc54300)
> "server-process-filter" (0xffc54558)
> "sit-for" (0xffc56658)
> "server--sit-for" (0xffc567e8)
> "server-return-error" (0xffc569b0)

I'm probably missing something, because I don't understand how come
server-process-filter is still being run after we reset the process
filter to nil...

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > +(defun server--sit-for (proc seconds)
>> > +  "Like `sit-for', but disable filter of process PROC and don't redisplay."
>> > +  (let ((orig-filter (process-filter proc)))
>> > +    (unwind-protect
>> > +        (progn
>> > +          (set-process-filter proc nil)
>> > +          (sit-for seconds t))
>> > +      (set-process-filter proc orig-filter))))
>> 
>> Hmm... (set-process-filter proc nil) means that any process output will
>> be sent to the process's buffer rather than to the filter, which doesn't
>> sound right (it will make us miss that process output, basically).
>> 
>> If we want this to work well we need to store the process output we
>> receive during the `sit-for` and call the process filter in it afterwards.
>
> At this point we don't expect any output from the process, and if it
> comes, don't want to know about it nor process it.

Why don't we want to process it?
[ I understand why we don't want to process it *now* but why wouldn't
  we want to process it later?  ]

>> Another option would be to offer a way to temporary suspend the
>> reception of process output for a specific process.  For most processes,
>> suspending reception of process output while running the process filter
>> would be the right thing to do, so even better would be to do that
>> automatically and offer instead a way for a process filter to explicitly
>> enable running itself recursively when/were it is needed.
> The problem here is that the process filter calls sit-for, which reads
> process output, which also calls the process filter, etc., etc. -- a

That was my understanding, indeed.  But that seems to contradict:

    At this point we don't expect any output from the process, and if it
    comes, don't want to know about it nor process it.

Oh... wait I think I understand: it's the same process-filter but not
the same process.  So your `set-process-filter` won't make
a difference and my suggestion to suspend reception of this process's
output won't help either.

>> We should devise a variant of `message` which guarantees that the message
>> is shown for at least N seconds but without having to wait for the
>> N seconds to pass before running the rest of the code.
> AFAIU, 'message' is not the problem, the problem is not to delete the
> process object too quickly, because that causes all kinds of
> unpleasant effects on the client side (see the bug reports related to
> changes in these areas).

In this specific case, it seems the relevant execution path goes through
one of the other `sit-for`, indeed.  But in theory the same could happen
with this `sit-for` so it would be good to get rid of it as well.

>> I think a better option here is to run the `delete-process` from
>> a timer, so we can *really* return immediately.
> Then, in the scenario of this bug report, we could have large amounts
> of processes we haven't chance to delete yet, because timers were not
> run before the next connection starts.

Sure.  I don't see why that would be a problem, tho.


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: n142857@gmail.com,  71223@debbugs.gnu.org
> Date: Mon, 27 May 2024 13:49:24 -0400
> 
> >> > +(defun server--sit-for (proc seconds)
> >> > +  "Like `sit-for', but disable filter of process PROC and don't redisplay."
> >> > +  (let ((orig-filter (process-filter proc)))
> >> > +    (unwind-protect
> >> > +        (progn
> >> > +          (set-process-filter proc nil)
> >> > +          (sit-for seconds t))
> >> > +      (set-process-filter proc orig-filter))))
> >> 
> >> Hmm... (set-process-filter proc nil) means that any process output will
> >> be sent to the process's buffer rather than to the filter, which doesn't
> >> sound right (it will make us miss that process output, basically).
> >> 
> >> If we want this to work well we need to store the process output we
> >> receive during the `sit-for` and call the process filter in it afterwards.
> >
> > At this point we don't expect any output from the process, and if it
> > comes, don't want to know about it nor process it.
> 
> Why don't we want to process it?

Because the session is being closed, and there's nothing the process
can tell us that is of interest.

> > The problem here is that the process filter calls sit-for, which reads
> > process output, which also calls the process filter, etc., etc. -- a
> 
> That was my understanding, indeed.  But that seems to contradict:
> 
>     At this point we don't expect any output from the process, and if it
>     comes, don't want to know about it nor process it.
> 
> Oh... wait I think I understand: it's the same process-filter but not
> the same process.

Exactly!

> So your `set-process-filter` won't make a difference and my
> suggestion to suspend reception of this process's output won't help
> either.

Hmm...

> >> I think a better option here is to run the `delete-process` from
> >> a timer, so we can *really* return immediately.
> > Then, in the scenario of this bug report, we could have large amounts
> > of processes we haven't chance to delete yet, because timers were not
> > run before the next connection starts.
> 
> Sure.  I don't see why that would be a problem, tho.

It will be on Windows, I think.  But feel free to suggest a patch
along these lines, and let's see if it solves the problem.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> Cc: n142857@gmail.com, 71223@debbugs.gnu.org
> Date: Mon, 27 May 2024 21:15:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > >> I think a better option here is to run the `delete-process` from
> > >> a timer, so we can *really* return immediately.
> > > Then, in the scenario of this bug report, we could have large amounts
> > > of processes we haven't chance to delete yet, because timers were not
> > > run before the next connection starts.
> > 
> > Sure.  I don't see why that would be a problem, tho.
> 
> It will be on Windows, I think.  But feel free to suggest a patch
> along these lines, and let's see if it solves the problem.

Alternatively, we could add a method of waiting without calling
wait_reading_process_output.  E.g., an additional argument to
sleep-for.  WDYT?

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Hi Daniel,

Could you try the patch below which sequentializes the processing of the
process-filters to avoid such recursion?


        Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: server.patch --]
[-- Type: text/x-diff, Size: 3347 bytes --]

diff --git a/lisp/server.el b/lisp/server.el
index b65053267a6..7d8b8d37fad 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -1046,6 +1046,8 @@ server-execute-continuation
     (process-put proc 'continuation nil)
     (if continuation (ignore-errors (funcall continuation)))))
 
+(defvar server--pending-filter-calls t)
+
 (cl-defun server-process-filter (proc string)
   "Process a request from the server to edit some files.
 PROC is the server process.  STRING consists of a sequence of
@@ -1145,6 +1147,18 @@ server-process-filter
 `-suspend'
   Suspend this terminal, i.e., stop the client process.
   Sent when the user presses \\[suspend-frame]."
+  (if (listp server--pending-filter-calls)
+      ;; We're already running another instance of this process filter.
+      ;; Let's make sure we don't run them in a nested fashion.
+      (push (cons proc string) server--pending-filter-calls)
+    (let ((server--pending-filter-calls nil))
+     (push (cons proc string) server--pending-filter-calls)
+     (while server--pending-filter-calls
+       (dolist (pending-call (prog1 (nreverse server--pending-filter-calls)
+                               (setq server--pending-filter-calls nil)))
+         (server--process-filter (car pending-call) (cdr pending-call)))))))
+
+(cl-defun server--process-filter (proc string)
   (server-log (concat "Received " string) proc)
   ;; First things first: let's check the authentication
   (unless (process-get proc :authenticated)
@@ -1159,6 +1173,9 @@ server-process-filter
       ;; it, in case the error written by emacsclient to stderr is not
       ;; visible for some reason.
       (message "Authentication failed")
+      ;; FIXME: Ideally we should not need `sit-for' here and instead use
+      ;; some `message-timed' call which makes sure the message is visible
+      ;; without forcing us to wait here.
       (sit-for 2)
       (server-send-string
        proc (concat "-error " (server-quote-arg "Authentication failed")))
@@ -1169,10 +1186,9 @@ server-process-filter
 	    (delete-terminal terminal))))
       ;; Before calling `delete-process', give emacsclient time to
       ;; receive the error string and shut down on its own.
-      (sit-for 1)
-      (delete-process proc)
+      (run-with-timer 1 nil #'delete-process proc)
       ;; We return immediately.
-      (cl-return-from server-process-filter)))
+      (cl-return-from server--process-filter)))
   (let ((prev (process-get proc 'previous-string)))
     (when prev
       (setq string (concat prev string))
@@ -1508,6 +1524,9 @@ server-return-error
     ;; it, in case the error written by emacsclient to stderr is not
     ;; visible for some reason.
     (message (error-message-string err))
+    ;; FIXME: Ideally we should not need `sit-for' here and instead use
+    ;; some `message-timed' call which makes sure the message is visible
+    ;; without forcing us to wait here.
     (sit-for 2)
     (server-send-string
      proc (concat "-error " (server-quote-arg
@@ -1520,7 +1539,7 @@ server-return-error
 	  (delete-terminal terminal))))
     ;; Before calling `delete-process', give emacsclient time to
     ;; receive the error string and shut down on its own.
-    (sit-for 5)
+    (run-with-timer 5 nil #'delete-process proc)
     (delete-process proc)))
 
 (defun server-goto-line-column (line-col)

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Alternatively, we could add a method of waiting without calling
> wait_reading_process_output.  E.g., an additional argument to
> sleep-for.  WDYT?

If at all possible, I'd rather not wait (register a callback instead).
As a general rule `sit-for` is a source of problems in ELisp code.


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Daniel Clemente]

> Could you try the patch below which sequentializes the processing of the
> process-filters to avoid such recursion?

Running on d9512da49514623ef3e35524dc894c06f2c0ce20 (from yesterday)
with only this patch, and a simple loop (10 seconds are enough):

for j in `seq 10`; do for i in `seq 10`; do urxvt -e emacsclient '-nw'
'-e' '(dired "~")' &; done; sleep 1 && killall emacsclient; done

(gdb) run --fg-daemon -Q
Starting program: /opt/dc/emacs/bin/emacs --fg-daemon -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Starting Emacs daemon.
[Detaching after vfork from child process 1028]
[Detaching after vfork from child process 1033]
[Detaching after vfork from child process 1034]
process server <5> no longer connected to pipe; closed it
Process server <6> not running: connection broken by remote peer

Process server <7> not running: connection broken by remote peer

Process server <8> not running: connection broken by remote peer

Process server <9> not running: connection broken by remote peer

Process server <10> not running: connection broken by remote peer

Process server <11> not running: connection broken by remote peer

Process server <12> not running: connection broken by remote peer

Process server <13> not running: connection broken by remote peer

Process server <14> not running: connection broken by remote peer

Process server <15> not running: connection broken by remote peer

Process server <16> not running: connection broken by remote peer

Process server <17> not running: connection broken by remote peer

Process server <18> not running: connection broken by remote peer

Process server <19> not running: connection broken by remote peer

Process server <20> not running: connection broken by remote peer

Process server <21> not running: connection broken by remote peer

Process server <22> not running: connection broken by remote peer

Process server <23> not running: connection broken by remote peer

Process server <24> not running: connection broken by remote peer

Process server <25> not running: connection broken by remote peer

Process server <26> not running: connection broken by remote peer

Process server <27> not running: connection broken by remote peer

[…]
(new message appearing every 2 seconds)

At that point, it's unresponsive and I can't open new emacsclient.
They open a black window, where after a time I see "Server not
responding". If I wait until all the "connection broken" errors slowly
end, then these frames will load (i.e. dired is visible), and new
frames will load too.

With casual usage, i.e. just opening a few frames and closing them
after they are fully loaded (visible text inside) there are no
"connection broken" messages. I think the error appears only when I'm
closing a frame that was still in the process of being opened.

I stopped it when it was hung:

^Z
Program received signal SIGTSTP, Stopped (user).
pselect64_syscall (sigmask=0x0, timeout=<optimized out>,
exceptfds=0x0, writefds=0x7fffffffa5b0, readfds=0x7fffffffa630,
nfds=14)
    at ../sysdeps/unix/sysv/linux/pselect.c:34
34    in ../sysdeps/unix/sysv/linux/pselect.c
(gdb) bt
#0  pselect64_syscall (sigmask=0x0, timeout=<optimized out>,
exceptfds=0x0, writefds=0x7fffffffa5b0, readfds=0x7fffffffa630,
nfds=14)
    at ../sysdeps/unix/sysv/linux/pselect.c:34
#1  __pselect (nfds=14, readfds=0x7fffffffa630,
writefds=0x7fffffffa5b0, exceptfds=0x0, timeout=<optimized out>,
sigmask=0x0)
    at ../sysdeps/unix/sysv/linux/pselect.c:56
#2  0x00005555557de65c in really_call_select (arg=0x7fffffffa370) at
thread.c:624
#3  0x00005555556ff539 in flush_stack_call_func1 (func=0x5555557de5c2
<really_call_select>, arg=0x7fffffffa370) at alloc.c:5534
#4  0x00005555557dda79 in flush_stack_call_func (func=0x5555557de5c2
<really_call_select>, arg=0x7fffffffa370) at /w/emacs/src/lisp.h:4507
#5  0x00005555557de717 in thread_select (func=0x7ffff551d980
<__pselect>, max_fds=14, rfds=0x7fffffffa630, wfds=0x7fffffffa5b0,
efds=0x0,
    timeout=0x7fffffffa590, sigmask=0x0) at thread.c:656
#6  0x00005555557a8c4e in wait_reading_process_output (time_limit=1,
nsecs=999978544, read_kbd=-1, do_display=true, wait_for_cell=XIL(0),
    wait_proc=0x0, just_wait_proc=0) at process.c:5752
#7  0x0000555555678b60 in kbd_buffer_get_event (kbp=0x7fffffffa968,
used_mouse_menu=0x0, end_time=0x7fffffffafe0) at keyboard.c:4058
#8  0x0000555555674cd7 in read_event_from_main_queue
(end_time=0x7fffffffafe0, local_getcjmp=0x7fffffffadb0,
used_mouse_menu=0x0)
    at keyboard.c:2330
#9  0x0000555555674f8b in read_decoded_event_from_main_queue
(end_time=0x7fffffffafe0, local_getcjmp=0x7fffffffadb0,
prev_event=XIL(0),
    used_mouse_menu=0x0) at keyboard.c:2394
#10 0x0000555555676735 in read_char (commandflag=0, map=XIL(0),
prev_event=XIL(0), used_mouse_menu=0x0, end_time=0x7fffffffafe0) at
keyboard.c:3015
#11 0x000055555576c91b in read_filtered_event (no_switch_frame=false,
ascii_required=false, error_nonascii=false, input_method=true,
    seconds=make_fixnum(2)) at lread.c:791
#12 0x000055555576cc8d in Fread_event (prompt=XIL(0),
inherit_input_method=XIL(0x30), seconds=make_fixnum(2)) at lread.c:941
#13 0x00007ffff18c8dbf in F7369742d666f72_sit_for_0 ()
   from /opt/dc/emacs/bin/../lib/emacs/30.0.50/native-lisp/30.0.50-ea7acd4b/preloaded/subr-13adf6a6-0e73955f.eln
#14 0x0000555555736ba3 in funcall_subr (subr=0x7ffff1a173b0,
numargs=1, args=0x7fffffffb208) at eval.c:3163
#15 0x0000555555736611 in funcall_general (fun=XIL(0x7ffff1a173b5),
numargs=1, args=0x7fffffffb208) at eval.c:3040
#16 0x00005555557368c2 in Ffuncall (nargs=2, args=0x7fffffffb200) at eval.c:3093
#17 0x00007ffff11943c3 in
F7365727665722d72657475726e2d6572726f72_server_return_error_0 ()
   from /home/dc/.emacs.d/eln-cache/30.0.50-ea7acd4b/server-0cc44189-25489db9.eln
#18 0x0000555555736ba3 in funcall_subr (subr=0x555555ee49f0,
numargs=2, args=0x7fffffffb3d0) at eval.c:3163
#19 0x0000555555736611 in funcall_general (fun=XIL(0x555555ee49f5),
numargs=2, args=0x7fffffffb3d0) at eval.c:3040
#20 0x00005555557368c2 in Ffuncall (nargs=3, args=0x7fffffffb3c8) at eval.c:3093
#21 0x00007ffff1191258 in
F7365727665722d2d70726f636573732d66696c746572_server__process_filter_0
()
   from /home/dc/.emacs.d/eln-cache/30.0.50-ea7acd4b/server-0cc44189-25489db9.eln
#22 0x0000555555736ba3 in funcall_subr (subr=0x555555ee4940,
numargs=2, args=0x7fffffffb628) at eval.c:3163
#23 0x0000555555736611 in funcall_general (fun=XIL(0x555555ee4945),
numargs=2, args=0x7fffffffb628) at eval.c:3040
#24 0x00005555557368c2 in Ffuncall (nargs=3, args=0x7fffffffb620) at eval.c:3093
#25 0x00007ffff1190dcc in
F7365727665722d70726f636573732d66696c746572_server_process_filter_0 ()
   from /home/dc/.emacs.d/eln-cache/30.0.50-ea7acd4b/server-0cc44189-25489db9.eln
#26 0x0000555555736ba3 in funcall_subr (subr=0x555555ee48e8,
numargs=2, args=0x7fffffffb7b8) at eval.c:3163
#27 0x0000555555736611 in funcall_general (fun=XIL(0x555555ee48ed),
numargs=2, args=0x7fffffffb7b8) at eval.c:3040
#28 0x00005555557368c2 in Ffuncall (nargs=3, args=0x7fffffffb7b0) at eval.c:3093
#29 0x0000555555735dc3 in Fapply (nargs=2, args=0x7fffffffb860) at eval.c:2765
#30 0x000055555573636e in apply1 (fn=XIL(0x118d50),
arg=XIL(0x7ffff2b56373)) at eval.c:2981
#31 0x00005555557a9b4a in read_process_output_call
(fun_and_args=XIL(0x7ffff2b56363)) at process.c:6130
#32 0x0000555555732f95 in internal_condition_case_1
(bfun=0x5555557a9b13 <read_process_output_call>,
arg=XIL(0x7ffff2b56363), handlers=XIL(0x90),
    hfun=0x5555557a9b50 <read_process_output_error_handler>) at eval.c:1637
#33 0x00005555557aa462 in read_and_dispose_of_process_output (p=0x5555565d77a0,
    chars=0x7fffffffb980 "-env MAIL=/var/mail/dc -env
LANGUAGE=en_US:en -env GTK_CSD=0 -env
WORKON_HOME=/home/dc/.virtualenvs -env USER=dc -env XDG_SEAT=seat0
-env VAGRANT_DISABLE_VBOXSYMLINKCREATE=1 -env SSH_AGENT_PID=1016
-e"..., nbytes=3744, coding=0x55555608a1f0) at process.c:6354
#34 0x00005555557aa06e in read_process_output
(proc=XIL(0x5555565d77a5), channel=17) at process.c:6264
#35 0x00005555557a92ee in wait_reading_process_output (time_limit=0,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0),
wait_proc=0x0,
    just_wait_proc=0) at process.c:5948
#36 0x0000555555678cf3 in kbd_buffer_get_event (kbp=0x7fffffffd008,
used_mouse_menu=0x7fffffffd68f, end_time=0x0) at keyboard.c:4079
#37 0x0000555555674cd7 in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffffd450, used_mouse_menu=0x7fffffffd68f)
    at keyboard.c:2330
#38 0x0000555555674f8b in read_decoded_event_from_main_queue
(end_time=0x0, local_getcjmp=0x7fffffffd450, prev_event=XIL(0),
    used_mouse_menu=0x7fffffffd68f) at keyboard.c:2394
#39 0x0000555555676735 in read_char (commandflag=1,
map=XIL(0x7ffff03edd83), prev_event=XIL(0),
used_mouse_menu=0x7fffffffd68f, end_time=0x0)
    at keyboard.c:3015
#40 0x0000555555686142 in read_key_sequence (keybuf=0x7fffffffd8a0,
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
    fix_current_buffer=true, prevent_redisplay=false,
disable_text_conversion_p=false) at keyboard.c:10728
#41 0x000055555567263c in command_loop_1 () at keyboard.c:1429
#42 0x0000555555732eee in internal_condition_case (bfun=0x555555672249
<command_loop_1>, handlers=XIL(0x90), hfun=0x5555556717eb <cmd_error>)
--Type <RET> for more, q to quit, c to continue without paging--
    at eval.c:1613
#43 0x0000555555671ea6 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1168
#44 0x00005555557323f5 in internal_catch (tag=XIL(0xfc60),
func=0x555555671e7c <command_loop_2>, arg=XIL(0x90)) at eval.c:1292
#45 0x0000555555671e38 in command_loop () at keyboard.c:1146
#46 0x000055555567138d in recursive_edit_1 () at keyboard.c:754
#47 0x0000555555671539 in Frecursive_edit () at keyboard.c:837
#48 0x000055555566da30 in main (argc=3, argv=0x7fffffffdec8) at emacs.c:2621
(gdb) xbacktrace
"sit-for" (0xffffb208)
"server-return-error" (0xffffb3d0)
"server--process-filter" (0xffffb628)
"server-process-filter" (0xffffb7b8)
(gdb)

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: n142857@gmail.com,  71223@debbugs.gnu.org
> Date: Tue, 28 May 2024 20:30:44 -0400
> 
> > Alternatively, we could add a method of waiting without calling
> > wait_reading_process_output.  E.g., an additional argument to
> > sleep-for.  WDYT?
> 
> If at all possible, I'd rather not wait (register a callback instead).
> As a general rule `sit-for` is a source of problems in ELisp code.

I didn't mean to wait in sit-for, I meant to wait ion a way that
doesn't read input from processes and doesn't do redisplay.

Queueing timers will not solve the problem, I suspect, but will likely
get us into a different one, since times are run by the main loop.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Could you try the patch below which sequentializes the processing of the
>> process-filters to avoid such recursion?
>
> Running on d9512da49514623ef3e35524dc894c06f2c0ce20 (from yesterday)
> with only this patch, and a simple loop (10 seconds are enough):
>
> for j in `seq 10`; do for i in `seq 10`; do urxvt -e emacsclient '-nw'
> '-e' '(dired "~")' &; done; sleep 1 && killall emacsclient; done
>
> (gdb) run --fg-daemon -Q
> Starting program: /opt/dc/emacs/bin/emacs --fg-daemon -Q
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Starting Emacs daemon.
> [Detaching after vfork from child process 1028]
> [Detaching after vfork from child process 1033]
> [Detaching after vfork from child process 1034]
> process server <5> no longer connected to pipe; closed it
> Process server <6> not running: connection broken by remote peer

AFAICT this is because you kill those processes with `killall
emacsclient` so when Emacs finally wants to send the "result" back, the
`process-send-string` fails with the above error.

IOW, I'm not sure it reflects a bug in Emacs.

> At that point, it's unresponsive and I can't open new emacsclient.
> They open a black window, where after a time I see "Server not
> responding". If I wait until all the "connection broken" errors slowly
> end, then these frames will load (i.e. dired is visible), and new
> frames will load too.

Actually, if you hit a key within the Emacs frame you presumably have
opened, it should finish those things without waiting (the 2s waits are
done with `sit-for` which waits only when there's no pending user input).

> With casual usage, i.e. just opening a few frames and closing them
> after they are fully loaded (visible text inside) there are no
> "connection broken" messages. I think the error appears only when I'm
> closing a frame that was still in the process of being opened.

IIUC this problem is not really new with my code (tho, I guess when the
process-filters are run in a nested fashion, the various `sit-for` can
be done in parallel, whereas with my patch they are done sequentially,
significantly increasing the visible delay when you have many such
requests).

The better solution is to eliminate the remaining `sit-for`s (e.g. using
some new `message-timed` function which displays a message during at
least N seconds but returns immediately), of course.


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> If at all possible, I'd rather not wait (register a callback instead).
>> As a general rule `sit-for` is a source of problems in ELisp code.
> I didn't mean to wait in sit-for, I meant to wait ion a way that
> doesn't read input from processes and doesn't do redisplay.

I really meant "If at all possible, I'd rather not wait" to apply to any
kind of waiting.  The second sentence (about `sit-for`) was correlated
but not directly connected.

> Queueing timers will not solve the problem, I suspect, but will likely
> get us into a different one, since timers are run by the main loop.

Why would running them from the main loop be a problem?


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

[ Hi Chong, see below a question for you.  ]

> Could you try the patch below which sequentializes the processing of the
> process-filters to avoid such recursion?

Here's a new version of the patch which fixes various shortcomings
I noticed while trying it out.  Also it shortens the wait times after
displaying a message by applying the `sit-for` principle of not waiting
if there's some "pending input" (where I consider `emacsclient`
processes to be pending inputs as well).  This way, the `sit-for`
waiting times don't accumulate so much.

Also I noticed a weird thing in

    commit 2a847524ab57b1b3d6eaa7e12b96be52dbb79509
    Author: Chong Yidong <cyd@gnu.org>
    Date:   Sat Oct 2 20:03:44 2010 -0400
    
        * lisp/server.el (server-process-filter, server-return-error): Give
        emacsclient time to shut down after receiving an error string.
        
        * etc/NEWS: Document tweak to emacsclient exit status.

    [...]
    diff --git a/lisp/server.el b/lisp/server.el
    index 0f1b0219a2c..e661f055e1a 100644
    --- a/lisp/server.el
    +++ b/lisp/server.el
    @@ -876,6 +876,9 @@ server-process-filter
           (server-log "Authentication failed" proc)
           (server-send-string
            proc (concat "-error " (server-quote-arg "Authentication failed")))
    +      ;; Before calling `delete-process', give emacsclient time to
    +      ;; receive the error string and shut down on its own.
    +      (sit-for 1)
           (delete-process proc)
           ;; We return immediately
           (return-from server-process-filter)))
    @@ -1129,6 +1132,9 @@ server-return-error
          proc (concat "-error " (server-quote-arg
                                  (error-message-string err))))
         (server-log (error-message-string err) proc)
    +    ;; Before calling `delete-process', give emacsclient time to
    +    ;; receive the error string and shut down on its own.
    +    (sit-for 5)
         (delete-process proc)))
     
     (defun server-goto-line-column (line-col)

Why do we wait for 5s in one spot but 1s in another?


        Stefan

[-- Attachment #2: server.patch --]
[-- Type: text/x-diff, Size: 4815 bytes --]

diff --git a/lisp/server.el b/lisp/server.el
index b65053267a6..06bba74bfd7 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -438,7 +438,8 @@ server-sentinel
        (ignore-errors
 	 (delete-file (process-get proc :server-file))))
   (server-log (format "Status changed to %s: %s"
-                      (process-status proc) msg) proc)
+                      (process-status proc) msg)
+              proc)
   (server-delete-client proc))
 
 (defun server--on-display-p (frame display)
@@ -1046,6 +1047,9 @@ server-execute-continuation
     (process-put proc 'continuation nil)
     (if continuation (ignore-errors (funcall continuation)))))
 
+(defvar server--pending-filter-calls nil)
+(defvar server--processing-pending-filters nil)
+
 (cl-defun server-process-filter (proc string)
   "Process a request from the server to edit some files.
 PROC is the server process.  STRING consists of a sequence of
@@ -1145,6 +1149,37 @@ server-process-filter
 `-suspend'
   Suspend this terminal, i.e., stop the client process.
   Sent when the user presses \\[suspend-frame]."
+  ;; Push this to the end of the list, so the list is in the order in which
+  ;; we need to process it.
+  ;; FIXME: This implies an O(N²) worst-case, which is not good:
+  ;; we should use a "true" O(N) queue.
+  (setq server--pending-filter-calls
+        (nconc server--pending-filter-calls (list (cons proc string))))
+  (unless server--processing-pending-filters
+    (server-process-pending-filters)))
+
+(defun server-process-pending-filters ()
+  (let ((server--processing-pending-filters t))
+    (unwind-protect
+        (while server--pending-filter-calls
+          (let* ((oldest (pop server--pending-filter-calls)))
+            (server--process-filter (car oldest) (cdr oldest))))
+      ;; In case we're exiting early (e.g. for `server-goto-toplevel'),
+      ;; make sure we continue running the other pending filters.
+      (when server--pending-filter-calls
+        (run-with-timer 0 nil #'server-process-pending-filters)))))
+
+(defun server--message-timed (time &rest args)
+  (apply #'message args)
+  ;; FIXME: Ideally we should not need `sit-for' here and instead use
+  ;; some `message-timed' call which makes sure the message is visible
+  ;; without forcing us to wait here.
+  ;; If there's already another process-filter pending, skip `sit-for',
+  ;; just as it does when there's pending user input.
+  (unless (consp server--pending-filter-calls)
+    (sit-for time)))
+
+(cl-defun server--process-filter (proc string)
   (server-log (concat "Received " string) proc)
   ;; First things first: let's check the authentication
   (unless (process-get proc :authenticated)
@@ -1158,8 +1193,7 @@ server-process-filter
       ;; Display the error as a message and give the user time to see
       ;; it, in case the error written by emacsclient to stderr is not
       ;; visible for some reason.
-      (message "Authentication failed")
-      (sit-for 2)
+      (server--message-timed 2 "Authentication failed")
       (server-send-string
        proc (concat "-error " (server-quote-arg "Authentication failed")))
       (unless (eq system-type 'windows-nt)
@@ -1169,10 +1203,10 @@ server-process-filter
 	    (delete-terminal terminal))))
       ;; Before calling `delete-process', give emacsclient time to
       ;; receive the error string and shut down on its own.
-      (sit-for 1)
-      (delete-process proc)
+      ;; FIXME: Why do we wait 1s here but 5s in the other one?
+      (run-with-timer 1 nil #'delete-process proc)
       ;; We return immediately.
-      (cl-return-from server-process-filter)))
+      (cl-return-from server--process-filter)))
   (let ((prev (process-get proc 'previous-string)))
     (when prev
       (setq string (concat prev string))
@@ -1507,8 +1541,7 @@ server-return-error
     ;; Display the error as a message and give the user time to see
     ;; it, in case the error written by emacsclient to stderr is not
     ;; visible for some reason.
-    (message (error-message-string err))
-    (sit-for 2)
+    (server--message-timed 2 (error-message-string err))
     (server-send-string
      proc (concat "-error " (server-quote-arg
                              (error-message-string err))))
@@ -1520,8 +1553,8 @@ server-return-error
 	  (delete-terminal terminal))))
     ;; Before calling `delete-process', give emacsclient time to
     ;; receive the error string and shut down on its own.
-    (sit-for 5)
-    (delete-process proc)))
+    ;; FIXME: Why do we wait 5s here but 1s in the other one?
+    (run-with-timer 5 nil #'delete-process proc)))
 
 (defun server-goto-line-column (line-col)
   "Move point to the position indicated in LINE-COL.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> Cc: 71223@debbugs.gnu.org
> Date: Wed, 29 May 2024 15:56:17 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> IIUC this problem is not really new with my code (tho, I guess when the
> process-filters are run in a nested fashion, the various `sit-for` can
> be done in parallel, whereas with my patch they are done sequentially,
> significantly increasing the visible delay when you have many such
> requests).

No, the nested sit-for calls are NOT running in parallel, because
there's just one thread running them all.  Only the innermost sit-for
is actually "running", in the sense that its pselect loop in waiting
for input.

So what your change does is replace a depth-first sequence of sit-for
with a kind-of breadth-first sequence.  But it's a sequence in either
case.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: n142857@gmail.com,  71223@debbugs.gnu.org
> Date: Wed, 29 May 2024 16:58:57 -0400
> 
> >> If at all possible, I'd rather not wait (register a callback instead).
> >> As a general rule `sit-for` is a source of problems in ELisp code.
> > I didn't mean to wait in sit-for, I meant to wait ion a way that
> > doesn't read input from processes and doesn't do redisplay.
> 
> I really meant "If at all possible, I'd rather not wait" to apply to any
> kind of waiting.  The second sentence (about `sit-for`) was correlated
> but not directly connected.

Then please explain why you think "any kind of waiting" is a source of
problems in Emacs.

> > Queueing timers will not solve the problem, I suspect, but will likely
> > get us into a different one, since timers are run by the main loop.
> 
> Why would running them from the main loop be a problem?

Because the main loop uses the same pselect call that reacts to input
from sub-processes which is called by sit-for, and moreover, adding
timers makes the main loop increase its looping rate.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> Cc: Daniel Clemente <n142857@gmail.com>, 71223@debbugs.gnu.org
> Date: Wed, 29 May 2024 17:07:34 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Why do we wait for 5s in one spot but 1s in another?

Please read the bug report(s) which resulted in each line.  At least
some of these times were calibrated by running specific use cases
where those bugs happened.  AFAIR, some of the waits were already
there, and I didn't change them just to follow the new waits I added,
because I didn't have a reason to do so.

AFAIR, the waits are for 2 purposes:

  . let the user of emacsclient see the error messages sent by the
    server (because deleting the process clears the terminal);
  . let the server and the client have enough time to undo the
    terminal settings they did when the session started, so that the
    terminal is left in workable condition after the client exits.

The bug(s) in question should tell the details.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Daniel Clemente]

> Here's a new version of the patch which fixes various shortcomings
> I noticed while trying it out.  Also it shortens the wait times after

Running with d9512da4951 (same as last time, though I enable glyph
debug), and only with this patch.

It seems faster. Messages appear instantly, new frames don't get
stuck. Everything works.

Most importantly, it doesn't overflow the Lisp stack. Immediately
after having opened+closed thousands of frames, I stopped the process
and the stack is small. Opening and closing new frames still works
instantly they work.

Even if I adjust the stress test timings to open+close frame faster
(e.g. sleep 0.5 instead of sleep 1), Emacs does it (slowly, because of
my -O0 build) and they work. My window manager crashed in the process!
(too many windows), but Emacs didn't. The stack is later ok.

I did another experiment which I couldn't do before: 20 minutes
opening+closing frames:
for j in `seq 1200`; do for i in `seq 10`; do urxvt -e emacsclient
'-nw' '-e' '(dired "~")' &; done; sleep 1 && killall emacsclient; done
It didn't hang or crash and I can use emacs normally after that.

Thanks. This simplifies testing and debugging other bugs which only
appear when stressing Emacs (e.g. bug#71176 was like that).

Log of a run, below. The error messages, as Stefan mentioned, are
because of killing emacsclient, and are not a bug. Though some
discussion points remain, about making sure the emacsclient user sees
the errors and the terminal is cleaned. By the way, see the 1 instance
of: Could not open file: /dev/pts/12



Starting program: /opt/dc/emacs/bin/emacs-30.0.50 --fg-daemon -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Starting Emacs daemon.
[Detaching after vfork from child process 4829]
[Detaching after vfork from child process 4830]
[Detaching after vfork from child process 4831]
process server <2> no longer connected to pipe; closed it
Process server <3> not running: connection broken by remote peer

Process server <4> not running: connection broken by remote peer

Process server <5> not running: connection broken by remote peer

Process server <6> not running: connection broken by remote peer

[…]

Process server <38> not running: connection broken by remote peer

Process server <39> not running: connection broken by remote peer

Process server <40> not running: connection broken by remote peer

process server <41> no longer connected to pipe; closed it
process server <42> no longer connected to pipe; closed it
process server <43> no longer connected to pipe; closed it
process server <44> no longer connected to pipe; closed it
process server <45> no longer connected to pipe; closed it
process server <46> no longer connected to pipe; closed it
process server <47> no longer connected to pipe; closed it
Process server <48> not running: connection broken by remote peer

Process server <49> not running: connection broken by remote peer

[…]

Process server <135> not running: connection broken by remote peer

Process server <136> not running: connection broken by remote peer

Process server <137> not running: connection broken by remote peer

Could not open file: /dev/pts/12
process server <139> no longer connected to pipe; closed it
process server <140> no longer connected to pipe; closed it
process server <141> no longer connected to pipe; closed it
process server <142> no longer connected to pipe; closed it
process server <143> no longer connected to pipe; closed it
process server <144> no longer connected to pipe; closed it
process server <145> no longer connected to pipe; closed it
process server <146> no longer connected to pipe; closed it
process server <147> no longer connected to pipe; closed it
Process server <148> not running: connection broken by remote peer

Process server <149> not running: connection broken by remote peer

[…]

Process server <2292> not running: connection broken by remote peer

Process server <2294> not running: connection broken by remote peer

Process server <2293> not running: connection broken by remote peer

Process server <2295> not running: connection broken by remote peer

^Z
Program received signal SIGTSTP, Stopped (user).
pselect64_syscall (sigmask=0x0, timeout=<optimized out>, exceptfds=0x0,
    writefds=0x7fffffffd030, readfds=0x7fffffffd0b0, nfds=11)
    at ../sysdeps/unix/sysv/linux/pselect.c:34
34    ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.

(gdb) bt

#0  pselect64_syscall (sigmask=0x0, timeout=<optimized out>, exceptfds=0x0,
    writefds=0x7fffffffd030, readfds=0x7fffffffd0b0, nfds=11)
    at ../sysdeps/unix/sysv/linux/pselect.c:34
#1  __pselect (nfds=11, readfds=0x7fffffffd0b0, writefds=0x7fffffffd030,
    exceptfds=0x0, timeout=<optimized out>, sigmask=0x0)
    at ../sysdeps/unix/sysv/linux/pselect.c:56
#2  0x000055555582c5e8 in really_call_select (arg=0x7fffffffcdf0) at
thread.c:624
#3  0x000055555572ffb2 in flush_stack_call_func1 (
    func=0x55555582c54e <really_call_select>, arg=0x7fffffffcdf0) at
alloc.c:5534
#4  0x000055555582b85a in flush_stack_call_func (
    func=0x55555582c54e <really_call_select>, arg=0x7fffffffcdf0)
    at /w/emacs/src/lisp.h:4507
#5  0x000055555582c6a3 in thread_select (func=0x7ffff551d980 <__pselect>,
    max_fds=11, rfds=0x7fffffffd0b0, wfds=0x7fffffffd030, efds=0x0,
    timeout=0x7fffffffd010, sigmask=0x0) at thread.c:656
#6  0x00005555557ee3e1 in wait_reading_process_output (time_limit=30, nsecs=0,
    read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0,
    just_wait_proc=0) at process.c:5752
#7  0x0000555555594eb9 in sit_for (timeout=make_fixnum(30), reading=true,
    display_option=1) at dispnew.c:6318
#8  0x0000555555695250 in read_char (commandflag=1, map=XIL(0x7ffff027e153),
    prev_event=XIL(0), used_mouse_menu=0x7fffffffd6af, end_time=0x0)
    at keyboard.c:2923
#9  0x00005555556a67ff in read_key_sequence (keybuf=0x7fffffffd8c0,
    prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
    fix_current_buffer=true, prevent_redisplay=false,
    disable_text_conversion_p=false) at keyboard.c:10728
#10 0x0000555555690ee7 in command_loop_1 () at keyboard.c:1429
#11 0x000055555576c6cf in internal_condition_case (
    bfun=0x555555690ab8 <command_loop_1>, handlers=XIL(0x90),
    hfun=0x55555568ff63 <cmd_error>) at eval.c:1613
#12 0x0000555555690696 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1168
#13 0x000055555576bafc in internal_catch (tag=XIL(0xfc60),
    func=0x55555569066c <command_loop_2>, arg=XIL(0x90)) at eval.c:1292
#14 0x0000555555690628 in command_loop () at keyboard.c:1146
#15 0x000055555568fa05 in recursive_edit_1 () at keyboard.c:754
#16 0x000055555568fc31 in Frecursive_edit () at keyboard.c:837
#17 0x000055555568b698 in main (argc=3, argv=0x7fffffffdee8) at emacs.c:2621
(gdb)

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> No, the nested sit-for calls are NOT running in parallel, because
> there's just one thread running them all.  Only the innermost sit-for
> is actually "running", in the sense that its pselect loop in waiting
> for input.

Hmm... the nested runs happens from within an outer `sit-for`, so the
time taken by the nested runs could/should count as part of the wait
time of the outer `sit-for`, thus sort of "running in parallel".

Apparently you're right, tho:

    (progn (run-with-timer 0 nil #'sit-for 2)
           (benchmark-call (lambda () (sit-for 2))))
    ==> (4.020784627 0 0.0)

but this looks like a bug in `sit-for` to me.  🙁

> So what your change does is replace a depth-first sequence of sit-for
> with a kind-of breadth-first sequence.  But it's a sequence in either
> case.

Indeed, the upside is that it means my patch doesn't make things worse
in this respect.  🙂


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Then please explain why you think "any kind of waiting" is a source of
> problems in Emacs.

As I tried to explain in my last email, I did not say that any kind of
waiting is a source of problems in Emacs.  I said that (in this
specific case) "if at all possible, I'd rather not wait".

And I said that the `sit-for` way of waiting is a source of problems
in Emacs (as a general rule).

>> > Queueing timers will not solve the problem, I suspect, but will likely
>> > get us into a different one, since timers are run by the main loop.
>> Why would running them from the main loop be a problem?
> Because the main loop uses the same pselect call that reacts to input
> from sub-processes which is called by sit-for, and moreover, adding
> timers makes the main loop increase its looping rate.

None of which sound like problems to me, so I must be missing something.


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: n142857@gmail.com,  71223@debbugs.gnu.org
> Date: Thu, 30 May 2024 09:40:40 -0400
> 
> >> > Queueing timers will not solve the problem, I suspect, but will likely
> >> > get us into a different one, since timers are run by the main loop.
> >> Why would running them from the main loop be a problem?
> > Because the main loop uses the same pselect call that reacts to input
> > from sub-processes which is called by sit-for, and moreover, adding
> > timers makes the main loop increase its looping rate.
> 
> None of which sound like problems to me, so I must be missing something.

I'm just thinking aloud.

If your current patch seems to solve the problem, and doesn't
reintroduce the bug(s) due to which I added those waits, feel free to
install it, and thanks.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> AFAIR, the waits are for 2 purposes:
>
>   . let the user of emacsclient see the error messages sent by the
>     server (because deleting the process clears the terminal);

In my patch these are mostly kept except they are short-circuited when
there's already some other emacsclient process filtering pending.
In practice this should rarely make a difference: you need to have at
least 3 more-or-less-concurrent emacsclients for the difference to show
up (the first is processed normally, and if there's no 3rd, then by the
time we process the second there's no other thing pending).

>   . let the server and the client have enough time to undo the
>     terminal settings they did when the session started, so that the
>     terminal is left in workable condition after the client exits.

These are kept in the form of timers instead of `sit-for`.

> The bug(s) in question should tell the details.

I don't know which bugs these are, sadly.
[ I must say I don't understand why we need to wait and then call
  `delete-process`.  ]


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cyd@stupidchicken.com,  n142857@gmail.com,  71223@debbugs.gnu.org
> Date: Thu, 30 May 2024 12:09:30 -0400
> 
> > AFAIR, the waits are for 2 purposes:
> >
> >   . let the user of emacsclient see the error messages sent by the
> >     server (because deleting the process clears the terminal);
> 
> In my patch these are mostly kept except they are short-circuited when
> there's already some other emacsclient process filtering pending.
> In practice this should rarely make a difference: you need to have at
> least 3 more-or-less-concurrent emacsclients for the difference to show
> up (the first is processed normally, and if there's no 3rd, then by the
> time we process the second there's no other thing pending).

I'm talking about the mostly-normal situation when a single client
connects and that results in an error.

> >   . let the server and the client have enough time to undo the
> >     terminal settings they did when the session started, so that the
> >     terminal is left in workable condition after the client exits.
> 
> These are kept in the form of timers instead of `sit-for`.
> 
> > The bug(s) in question should tell the details.
> 
> I don't know which bugs these are, sadly.

"git log -L" indicates that it's bug#63629.

> [ I must say I don't understand why we need to wait and then call
>   `delete-process`.  ]

Because delete-process disconnects us from the terminal, and if we do
that too soon, then neither the error message we sent to the client
nor even the terminal resetting commands will get to their
destination.  Or so I concluded at the time; I don't consider myself
an expert on this stuff.

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> In my patch these are mostly kept except they are short-circuited when
>> there's already some other emacsclient process filtering pending.
>> In practice this should rarely make a difference: you need to have at
>> least 3 more-or-less-concurrent emacsclients for the difference to show
>> up (the first is processed normally, and if there's no 3rd, then by the
>> time we process the second there's no other thing pending).
>
> I'm talking about the mostly-normal situation when a single client
> connects and that results in an error.

Right, and indeed my code is careful to wait just like old code did, in
that case.

>> >   . let the server and the client have enough time to undo the
>> >     terminal settings they did when the session started, so that the
>> >     terminal is left in workable condition after the client exits.
>> 
>> These are kept in the form of timers instead of `sit-for`.
>> 
>> > The bug(s) in question should tell the details.
>> 
>> I don't know which bugs these are, sadly.
>
> "git log -L" indicates that it's bug#63629.

Hmm... I wonder I didn't see it in my `vc-region-history`...
Oh, that's because it's something else:

    commit d6f717cd1dc373707440011a1552b78de2654bba
    Author: Eli Zaretskii <eliz@gnu.org>
    Date:   Fri May 26 13:20:56 2023 +0300
    
        Fix emacsclient when there are irrecoverable file-visiting errors
        
        * lisp/server.el (server-process-filter, server-return-error):
        Display the error message to be sent to the client as a regular
        message, to give the user the opportunity to see it.  Delete the
        terminal immediately after sending the error message to the
        client, to make sure the terminal's modes are restored.
        (Bug#63629)

is the one where we add the "message + sit-for for 2 seconds" as well as
the calls to `delete-terminal`.
[ Code which I mostly leave untouched, at least for the "simple" case
  of a single emacsclient at a time.  ]

Whereas my question is about

    commit 2a847524ab57b1b3d6eaa7e12b96be52dbb79509
    Author: Chong Yidong <cyd@gnu.org>
    Date:   Sat Oct 2 20:03:44 2010 -0400
    
        * lisp/server.el (server-process-filter, server-return-error): Give
        emacsclient time to shut down after receiving an error string.
        
        * etc/NEWS: Document tweak to emacsclient exit status.

which added the two `sit-for`s (of 1s and 5s respectively) just before
`delete-process`.

>> [ I must say I don't understand why we need to wait and then call
>>   `delete-process`.  ]
>
> Because delete-process disconnects us from the terminal, and if we do
> that too soon, then neither the error message we sent to the client
> nor even the terminal resetting commands will get to their
> destination.  Or so I concluded at the time; I don't consider myself
> an expert on this stuff.

I find it odd that "send" followed by "delete process" can result in the
send being lost, tho.  It seems like it reflects a bug somewhere else.
But I'm not an expert in this at all either.  E.g. I can't remember why
we need to `delete-process`.


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

OK, I think I understand the code well enough now that I'm confident my
current patch is an overall improvement, and pushed it to `master`.

I think the problem is not completely specific to server.el's process
filter, so it might be be worthwhile to add some more generic support
for this kind of situation (e.g. ways to force some process filters to
be run sequentially rather than in a nested fashion, as well as ways for
process filters to know if there's already more work pending so as to
better handle bursts of concurrent requests).  I also still have some
FIXMEs in the code (one for `server--message-sit-for` which I think
deserves to be better implemented and moved to core, and another for the
question of the 5s vs 1s).

But w.r.t this bug report, I think we're done, so I'm closing it.


        Stefan

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cyd@stupidchicken.com,  n142857@gmail.com,  71223-done@debbugs.gnu.org
> Date: Thu, 30 May 2024 18:39:02 -0400
> 
> OK, I think I understand the code well enough now that I'm confident my
> current patch is an overall improvement, and pushed it to `master`.
> 
> I think the problem is not completely specific to server.el's process
> filter, so it might be be worthwhile to add some more generic support
> for this kind of situation (e.g. ways to force some process filters to
> be run sequentially rather than in a nested fashion, as well as ways for
> process filters to know if there's already more work pending so as to
> better handle bursts of concurrent requests).  I also still have some
> FIXMEs in the code (one for `server--message-sit-for` which I think
> deserves to be better implemented and moved to core, and another for the
> question of the 5s vs 1s).
> 
> But w.r.t this bug report, I think we're done, so I'm closing it.

Thanks.  I take it that you verified that the scenario of bug#63629
still works correctly after your changes?

bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Thanks.  I take it that you verified that the scenario of bug#63629
> still works correctly after your changes?

Worked for me, yes.


        Stefan