[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39962: 27.0.90; Crash in Emacs 27.0.90

From: Pieter van Oostrum
Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 18:42:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (darwin)

Eli Zaretskii <address@hidden> writes:

>> From: Pip Cet <address@hidden>
>> Date: Thu, 12 Mar 2020 20:00:13 +0000
>> Cc: address@hidden, Paul Eggert <address@hidden>
>> 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.  FWIW, the MS-Windows build have
> been using a 8MB run-time stack for a very long time.

My ulimit -s was 8192 (8 MiBi if I am correct).
The maximum I can set it to is 65532 (that's 64 MiBi if I am correct).

> Of course, given enough recursive data structures we can always crash
> the current GC the way it is implemented.  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?  IOW,
> I think we need to know how close we are in real-life sessions to the
> dangerous mark.

One file had 5063 messages, another one 2374.
But I was resorting these files, so I don't know if these caused more of these 
entries to be generated. The sorting has to reorder the messages, so I get the 
total would double, but they would be separate lists.

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

Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]