GNU bug report logs - #27585
segfault when evaluating a file containing only backticks

Previous Next

Full log

View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>,Steve Kemp <steve <at> steve.org.uk>
Cc: 27585 <at> debbugs.gnu.org
Subject: bug#27585: segfault when evaluating a file containing only backticks
Date: Thu, 06 Jul 2017 08:48:44 -0700

On July 5, 2017 11:41:45 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Steve Kemp <steve <at> 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"?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.