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

[Eli Zaretskii <eliz@gnu.org>]

> 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.