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

[Dan Douglas]

On 10/05/2017 02:29 PM, Dan Douglas wrote:
> ...

Another band-aid might be to build bash with -fsplit-stack. Hardly
worth mentioning as it doesn't fix anything - you just run out of memory
instead of overflowing a fixed-size stack, should someone actually want
that for some reason.



signature.asc
Description: OpenPGP digital signature

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

[Dan Douglas]

On 09/25/2017 01:38 PM, Eric Blake 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.
> 
> 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.
> 

If a shell (that's interpreted) crashes due to overflowing its process's
actual call stack it can only be because the shell's "call_function"
function (or its callees) call call_function, and call_function is not
itself tail-recursive so the C compiler can't eliminate it. It should
be perfectly possible to implement that without any recursion so the
shell's stack representation (presumably on the heap) can grow without
affecting the real stack for EVERY call to any trivial shell function. I
don't know what kind of major surgery would be required on bash to fix
that. libsigsegv would only be a band-aid.



signature.asc
Description: OpenPGP digital signature

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

[Shlomi Fish]

Hi all,

On Mon, 25 Sep 2017 13:38:01 -0500
Eric Blake  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.

Regards,

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/
http://www.shlomifish.org/humour/bits/New-versions-of-the-GPL/

“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 .

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

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

[Greg Wooledge]

On Sun, Sep 24, 2017 at 08:53:46PM +0300, 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 only applies to applications, not to tools that let YOU write
applications.

I can write a trivial C program that gcc will compile into a program
that segfaults.  That doesn't mean gcc has a bug.  It means my C program
has a bug.

Likewise, if you write a shell script that causes a shell to recurse
infinitely and exceed its available stack space, the bug is in your
script, not in the shell that faithfully tried to run it.

(See also Chet's two replies pointing to FUNCNEST.)

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

[Chet Ramey]

On 9/24/17 1: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. Perhaps implement a maximal
> recursion depth like zsh does. 

Perhaps read the documentation about the FUNCNEST variable. You get to
decide how much recursion you want.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

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

[Shlomi Fish]

Hi all,

On Sun, 24 Sep 2017 19:24:10 +0300
Pierre Gaston  wrote:

> On Sun, Sep 24, 2017 at 5:01 PM, Shlomi Fish  wrote:
> 
> > Hi all,
> >
> > With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
> > reported sytems:
> >
> > shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ;
> > run'
> > Segmentation fault (core dumped)
> > shlomif@telaviv1:~$
> >  
> 
> This, or some, variant has been reported multiple times.
> Like in most programming languages, you can easily write programs that
> behave badly,
> in this case you are exhausting the stack has there is no tail call
> optimization.
> 

I see. Well, the general wisdom is that a program should not ever segfault, but
instead gracefully handle the error and exit. Perhaps implement a maximal
recursion depth like zsh does. Also see the first item at
https://www.joelonsoftware.com/2007/02/19/seven-steps-to-remarkable-customer-service/
about permanently fixing reported problems at their core instead of dealing
with user reports and requests time and again.

Regards,

Shlomi

> see for instance
> https://lists.gnu.org/archive/html/bug-bash/2012-09/msg00073.html
> and the following discussion
> https://lists.gnu.org/archive/html/bug-bash/2012-10/threads.html#5



-- 
-
Shlomi Fish   http://www.shlomifish.org/
https://youtu.be/GoEn1YfYTBM - Tiffany Alvord - “Fall Together”

Chuck Norris does not keep any numbers on his mobile phone’s address book.
Instead, he memorised the entire phone directory.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

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

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

[Pierre Gaston]

On Sun, Sep 24, 2017 at 5:01 PM, Shlomi Fish  wrote:

> Hi all,
>
> With bash git master on Mageia v7 x86-64, bash on Debian Stable and other
> reported sytems:
>
> shlomif@telaviv1:~$ /home/shlomif/apps/bash/bin/bash -c 'run() { run; } ;
> run'
> Segmentation fault (core dumped)
> shlomif@telaviv1:~$
>

This, or some, variant has been reported multiple times.
Like in most programming languages, you can easily write programs that
behave badly,
in this case you are exhausting the stack has there is no tail call
optimization.

see for instance
https://lists.gnu.org/archive/html/bug-bash/2012-09/msg00073.html
and the following discussion
https://lists.gnu.org/archive/html/bug-bash/2012-10/threads.html#5