[Top][All Lists]

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

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

From: Daniel Colascione
Subject: bug#27585: segfault when evaluating a file containing only backticks
Date: Thu, 06 Jul 2017 08:48:44 -0700
User-agent: K-9 Mail for Android

On July 5, 2017 11:41:45 AM PDT, Eli Zaretskii <address@hidden> wrote:
>> From: Steve Kemp <address@hidden>
>> Date: Wed, 05 Jul 2017 06:21:10 +0000
>>   I've recently started fuzzing GNU Emacs, using the current git
>>  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"?

reply via email to

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