[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: Eric Blake
Subject: Re: SEGFAULT if bash script make "source" for itself
Date: Thu, 28 Aug 2014 15:57:19 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0

On 08/28/2014 03:50 PM, address@hidden wrote:
> Any action in my script should lead to SIGSEGV in interpreter! If I write
> program on some compilable language, for example C, compile it and got
> SIGSEGV - this is my problem. But in this case, my program executed by
> interpreter, and if interpreter fail, despite reasons, this is problem of
> interpreter.

No, it is a problem of your buggy program.

> What you will say if gcc(cc) will down with SIGSEGV while compiling your
> code? Is it problem of gcc or your code?

If gcc segfaults because it implements #include via recursion, and I
wrote a recursion loop of #includes into my source, then I'd say the bug
was mine, not gcc's.  Just the same as if you write a recursion loop
into your bash program.

It's not the compiler's fault that input that requests recursion can
abuse the stack.  Rather, it is the fault of the input.

> To be short - you(community) don't want to add limit, because its default
> value shoul be infinite!

I'm not saying that a limit is a bad idea, just that a limit on by
default is a bad idea (it goes against the GNU Coding Standards of no
arbitrary limits).  The moment YOU change from the default of unlimited
to your chosen limit, it is no longer an arbitrary limitation of bash,
but a conscious choice on your part.  But as long as the limit defaults
to being off, it brings us back to the question of whether bash should
dump core when the stack overflows due to a buggy user input.  It's not
a bug in bash, but in the user program; and that's WHY libsigsegv exists
(to convert what would have been a core dump into a nice error message,
making it obvious that the bug was in the user input).

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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