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

[Eric Blake]

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.

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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature