[Top][All Lists]

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

Re: [BUG] Bash segfaults on an infinitely recursive funcion (resend)

From: Shlomi Fish
Subject: Re: [BUG] Bash segfaults on an infinitely recursive funcion (resend)
Date: Wed, 4 Oct 2017 21:15:45 +0300

Hi all,

On Mon, 25 Sep 2017 13:38:01 -0500
Eric Blake <address@hidden> wrote:

> On 09/24/2017 12:53 PM, Shlomi Fish wrote:
> > 
> > I see. Well, the general wisdom is that a program should not ever segfault,
> > but instead gracefully handle the error and exit.  
> This is possible by installing a SIGSEGV handler that is able to
> gracefully exit the program when stack overflow is detected (although
> such a handler is EXTREMELY limited in what it is able to safely do); in
> fact, the GNU libsigsegv library helps in this task, and is used by some
> other applications (such as GNU m4 and GNU awk) that also can cause
> infinite recursion on poor user input. However, Chet is not obligated to
> use it (even though the idea has been mentioned on the list before).
> > Perhaps implement a maximal
> > recursion depth like zsh does.  
> Bash does, in the form of FUNCNEST, but you have to opt into it, as
> otherwise it would be an arbitrary limit, and arbitrary limits go
> against the GNU coding standards.

thanks for all the replies! All I can suggest is that FUNCNEST will have a
reasonable, but overridable and voidable default by default. Not sure if this
is an acceptable solution.


        Shlomi Fish 
> By the way, it is in general IMPOSSIBLE to write bash so that it can
> handle ALL possible bad user scripts and still remain responsive to
> further input.  Note that in my description of handling SIGSEGV above
> that I mention that it is only safe to gracefully turn what would
> otherwise be the default core dump into a useful error message - but
> bash STILL has to exit at that point, because you cannot guarantee what
> other resources (including malloc locks) might still be on the stack,
> where a longjmp back out to the main parsing loop may cause future
> deadlock if you do anything unsafe.  If you think you can make bash
> gracefully handle ALL possible bad inputs WITHOUT exiting or going into
> an infloop itself, then you are claiming that you have solved the
> Halting Problem, which any good computer scientist already knows has
> been proven to be undecidable.

Shlomi Fish       http://www.shlomifish.org/

“If it’s not bloat, it’s not us.”, said Richard Stallman, the colourful head of
the GNU project, and started to sing the Free Software song.
    — “The GNU Project Will Integrate GNU Guile into GNU coreutils”

Please reply to list if it's a mailing list post - http://shlom.in/reply .

reply via email to

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