[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 <eliz@gnu.org> writes:
>> From: Pip Cet <pipcet@gmail.com>
>> Date: Thu, 12 Mar 2020 20:00:13 +0000
>> Cc: 39962@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
>>
>> 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]
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, (continued)
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/12
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pip Cet, 2020/03/12
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pip Cet, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Richard Stallman, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/14
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pip Cet, 2020/03/14
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pip Cet, 2020/03/14
- bug#39962: 27.0.90; Crash in Emacs 27.0.90,
Pieter van Oostrum <=
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/13
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/14
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/14
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/15
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/15
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/15
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pieter van Oostrum, 2020/03/16
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Eli Zaretskii, 2020/03/16
- bug#39962: 27.0.90; Crash in Emacs 27.0.90, Pip Cet, 2020/03/16