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

[bogun.dmitriy]

2014-08-28 11:30 GMT-07:00 Eric Blake <eblake@redhat.com>:

> On 08/28/2014 12:02 PM, bogun.dmitriy@gmail.com 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.
>
> 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.

>
> As to whether or not user code should be able to cause stack overflow,
> we can't prevent it.  Reliably preventing stack overflow would be
> equivalent to solving the Halting Problem, which we cannot do; so all we
> can do is detect when it happens.
>
If follow this logic - we shoul try to catch incorrect user behaviour... we
will got errors/signals from kernel.

Simple situation:
$ ((1/0))
bash: ((: 1/0: division by 0 (error token is "0")

Whey there is check on division by zero? We can predict this? - No. But we
can detect it... and we out nice, detailed error message.

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

>
> >
> > 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.
>
> The GNU Coding Standards state that GNU software cannot have arbitrary
> limits by default.  Any limit we pick, other than unlimited (your
> proposal of turning it to 0), would be an arbitrary limit for someone
> who has a machine with more memory and a larger stack.  So 0 is the only
> sane default, but that's no different than what we already have.


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

 $ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30847
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 30847
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
dbogun@dbogun-bt-laptop ~ $

so... in real life we have a limits. Some of them turned off, but they
exists and can be ajusted.

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.



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