[Top][All Lists]

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

Re: SEGFAULT if bash script make "source" for itself

From: bogun.dmitriy
Subject: Re: SEGFAULT if bash script make "source" for itself
Date: Thu, 28 Aug 2014 11:02:36 -0700

IMHO any user action should not lead to SIGSEGV! I am not objecting against
recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
idea why this is happened. I have made recursive "sourse" by mistake and
spend a lot of time looking up what exactly lead to SIGSEGV.

Put a configurable limit on the deep of recursive source. There is almost
no variant for legal usage of recursive source on deep... 10000 for
example. If someone need such recursion deep, he alway can raise limit or
turn it off by setting it to 0.

PS Perhaps recursive function execution need limit too.

2014-08-28 9:48 GMT-07:00 Eric Blake <address@hidden>:

> On 08/27/2014 07:07 PM, address@hidden wrote:
> >
> > Expected result:
> > Block "source" for files already listed in "${BASH_SOURCE}". Perhaps this
> > behavior and "changed" behavior should be switched by option in "set"
> > command.
> No.  Recursive sourcing is useful, don't prohibit it artificially.
> Detecting which cases of user input would cause stack overflow is
> equivalent to solving the Halting Problem, which is not practical.  So
> our choices are to either cripple the user unnecessarily, or do a better
> job in at least detecting after the fact when the user did something dumb.
> >
> > Or at least suitable error message if recursive "source" loop detected.
> GNU libsigsegv is a library which provides the means for applications to
> give a NICE error message when user input causes stack overflow.  For
> example, both m4 and gawk use it so that a stack recursion exits
> gracefully rather than with a segfault and core dump (after all, it's
> the user's fault for putting in bad input, not a bug in the program).
> Maybe it's worth investigating if bash could link with it?
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

reply via email to

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