bug#27585: segfault when evaluating a file containing only backticks

[Daniel Colascione]

On July 5, 2017 11:41:45 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Steve Kemp <steve@steve.org.uk>
>> Date: Wed, 05 Jul 2017 06:21:10 +0000
>> 
>> 
>>   I've recently started fuzzing GNU Emacs, using the current git
>sources.
>>  During the course of that work I stumbled upon this easily
>reproduced bug:
>> 
>>    deagol ~ $ perl -e 'print "`" x ( 1024 * 1024  * 12);' > t.el
>>    deagol ~ $ /usr/bin/emacs --batch --script ./t.el
>>    ..
>>    Segmentation fault (core dumped)
>
>Here it says:
>
>  Re-entering top level after C stack overflow
>
>and doesn't crash.
>
>> > Most likely just a stack overflow.
>> 
>>   Agreed, but still I think a segfault is unexpected and could be
>>  prevented.
>
>See above: the machinery to try and prevent it exists, but it doesn't
>always succeed.  And it really can't be 100% reliable.  So I'm unsure
>what did you expect, and why.  Emacs generally gives you enough rope
>to hang yourself; it's up to you not to be tempted to do so...

This argument doesn't make sense to me. If we're happy letting elisp segfault, 
why bounds check AREF? 

Other managed runtimes --- Java, C# --- are perfectly capable of reliably 
detecting and recovering from stack exhaustion. There is absolutely no reason, 
aside from an implementation defect, for the elisp runtime not to do the same.

Stack overflow detection could be made perfectly reliable.


>
>IOW: why would someone want to run such a silly "program"?