bug-bash
[Top][All Lists]
Advanced

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

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


From: Bob Proulx
Subject: Re: SEGFAULT if bash script make "source" for itself
Date: Thu, 28 Aug 2014 14:59:07 -0600
User-agent: Mutt/1.5.23 (2014-03-12)

address@hidden wrote:
> Eric Blake wrote:
> > address@hidden wrote:
> > > 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.

But you wrote the program that caused the SIGSEGV.  At that point you
are no longer just a user but are now a programmer.  Technically
speaking the SIGSEGV problem would be a bug in your bash script
program.  You as the programmer of that script have the responsibility
for it.

> > SIGSEGV is what happens on stack overflow, unless you integrate a stack
> > overflow detector like GNU libsigsegv with your sources to catch the
> > segv and replace it with a nice error message.
>
> I know when and why program can get SIGSEGV.

Then you already know that it is a recursion problem that has run out
of stack space.  Any program that allows recursion might be programmed
in error.  If this is not suitable then using a programming language
that does not allow recursion might be the choice for you.  For
example the old FORTRAN did not allow recursion and yet it enjoyed a
lot of popularity at one time.

> So why I should got SIGSEGV instead of nice, detailed error message in
> recursion? We can detect it?

Because in general it is a hard problem to solve.  And it isn't always
about making it bigger.  It may simply be a very small environment
without enough stack to complete.  The program may completely fine if
there were enough stack.  It is hard to tell if the program is in an
infinite recursion or if it simply didn't have enough stack space to
complete and would complete if there were more.  All that can be said
is that it didn't have enough stack.

> > The GNU Coding Standards state that GNU software cannot have arbitrary
> > limits by default.  Any limit we pick, other than unlimited (your
> > ...
>
> IBM produce new CPU - it solve infinite loop in 8 seconds.
> 
> How bigger amount of memory save from infinite recursion? It lead to bigger
> delay before SIGSEGV and nothing else.

Haha.  Of course it is a hardware problem.  If we only had a machine
with an infinitely large stack then we would never run out of stack
space and could never SIGSEGV due to stack overflow.

Of course then the program would simply run forever since it would
continue to do exactly what it had been programmed to do.  Which is
one of the things that makes this so hard.  In order for an automated
detection the program must say that the program should not do what the
programmer told it to do.  That is where it runs into problems.
Similar to why auto-correction spell checkers force so many spelling
errors on humans.

>  $ ulimit -a
> data seg size           (kbytes, -d) unlimited
> ...
> 
> so... in real life we have a limits. Some of them turned off, but they
> exists and can be ajusted.

Those are explicit process limits in addition to the actual limits.
It is always easier to make them smaller.  But you can't make the
actual limits larger.

For example feel free to try to make use of that unlimited data set
size.  Let's assume you have a X sized memory machine.  Try to use a
thousand times X that amount of memory regardless of it being set to
unlimited and see how well things work.

> And if I have an option, which I can change to some suitable value for me
> and this can save me/show me good error message in case of infinite
> recursion - I will use it. Other can leave it in ifinite position. We can
> have 2 options - one set recursion level limit, other set action when this
> limit is reached - deny deeper recursion / print warning.

There is the sharp kitchen knife thought-problem.  Have you ever cut
yourself on a kitchen knife?  Of course most of us have at one time or
another.  Can you envision a way to make kitchen knives safer?  A way
to make it impossible for you to cut yourself on one?  Think about how
you would make a kitchen knife safer.  Give it a serious think.  Then
ask yourself this question.  Would you use such a knife that you
designed yourself?  The answer is invariable no.  There has always
been some inherent danger when using a kitchen knife.  We accept this
because the alternatives are all worse.

Bob



reply via email to

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