bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pip Cet]

On Fri, Mar 13, 2020 at 8:08 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > The first attachment to this message is an Elisp file which does the
> > same thing, by creating thousands of symbols. On GNU/Linux, with
> > fairly default standard stack size settings, I get a segfault after
> > some 85,000 symbols have been created.
>
> The default stack size on GNU/Linux is 2MB, right?  Maybe it's high
> time we raised that, what with the memory size today's machines
> routinely have at their disposal.

Well, it's just virtual memory, so raising it shouldn't be a problem,
though apparently the stack size is limited to 4 GB.

> FWIW, the MS-Windows build have
> been using a 8MB run-time stack for a very long time.

"ulimit -s" produces 9788 here.

> Of course, given enough recursive data structures we can always crash
> the current GC the way it is implemented.

Absolutely.

> But the question is how
> many such recursive symbols are there in Pieter's sessions? are they
> anywhere near the 1000000000 mark you used in your test program?

If I'm reading the code correctly, the recursion depth is equal to the
number of messages in VM's list, so a few tens of thousands of symbols
seem possible. Not anywhere near a billion, though.

> IOW,
> I think we need to know how close we are in real-life sessions to the
> dangerous mark.

It should certainly be possible to warn the user when stack usage
during GC exceeded a given percentage of the possible stack size;
hopefully, that would happen at least once before a crash.

It would also be possible to modify the code in sysdep.c to report
when it has detected an unrecoverable stack overflow.

> Maybe this is also worth reporting to VM developers.  They might
> consider changing their implementation to avoid these problems.

I think this is a VM-specific problem, not anything that we should be
changing GC code on the release branch for.

Do you happen to know whether anyone is looking at gcc -fsplit-stack
support for Emacs? That would avoid the problem entirely but allow us
to keep our current GC code.