Bug 1118978

Created attachment 917530 [details]
File: backtrace

Created attachment 917531 [details]
File: cgroup

Created attachment 917532 [details]
File: core_backtrace

Created attachment 917533 [details]
File: dso_list

Created attachment 917534 [details]
File: environ

Created attachment 917535 [details]
File: exploitable

Created attachment 917536 [details]
File: limits

Created attachment 917537 [details]
File: maps

Created attachment 917538 [details]
File: open_fds

Created attachment 917539 [details]
File: proc_pid_status

Created attachment 917540 [details]
File: var_log_messages

Looking at the backtrace, I think this is another bugzilla where bash got killed by infinite recursion.

Please try:
ulimit -s unlimited
FUNCNEST=256 FFOOD_DEBUG=true ffmanage

Unless it crashes again, not having FUNCNEST set by default is the correct intended behaviour, which may result in a SIGSEGV on resource depletion(doesn't even have to be the stack).

(In reply to Ondrej Oprala from comment #12)

Yes, it's infinite recursion.  In fact, you can reproduce the crash with as little as:

    fn() {
        fn
    }
    fn


> Please try:
> ulimit -s unlimited
> FUNCNEST=256 FFOOD_DEBUG=true ffmanage

With unlimited stack size, the script seems to go on and on forever (or until some resource depletion which could be after a very long time).


> Unless it crashes again, not having FUNCNEST set by default is the correct
> intended behaviour, which may result in a SIGSEGV on resource
> depletion(doesn't even have to be the stack).

I'm not sure I understand.  Do you mean that it's OK to segfault when stack limit is reached (vs. rerporting error and exitting gracefully)?  In that case, you can close this as NOTABUG.


(Other thing I found out is that FUNCNEST does not seem to have any effect; even set at 1, bash happily recurses forever ... that is another bug, am I right?)

(In reply to Alois Mahdal from comment #13)
> (In reply to Ondrej Oprala from comment #12)
> 
> Yes, it's infinite recursion.  In fact, you can reproduce the crash with as
> little as:
> 
>     fn() {
>         fn
>     }
>     fn
> 
> 
> > Please try:
> > ulimit -s unlimited
> > FUNCNEST=256 FFOOD_DEBUG=true ffmanage
> 
> With unlimited stack size, the script seems to go on and on forever (or
> until some resource depletion which could be after a very long time).

Yes, that's expected.
> 
> > Unless it crashes again, not having FUNCNEST set by default is the correct
> > intended behaviour, which may result in a SIGSEGV on resource
> > depletion(doesn't even have to be the stack).
> 
> I'm not sure I understand.  Do you mean that it's OK to segfault when stack
> limit is reached (vs. rerporting error and exitting gracefully)?  In that
> case, you can close this as NOTABUG.

Basically, yes. The mechanism similar to FUNCNEST is what all the shells use. The difference between bash and e.g. zsh/ksh is that bash has no default value
for FUNCNEST and allows recursing "infinitely" by default.
> 
> (Other thing I found out is that FUNCNEST does not seem to have any effect;
> even set at 1, bash happily recurses forever ... that is another bug, am I
> right?)

Interesting. I am unable to reproduce that. However yes, that would be another bug.

Closing this bz.

Cleaning up my attic...

(In reply to Ondrej Oprala from comment #14)
[...]
> > (Other thing I found out is that FUNCNEST does not seem to have any effect;
> > even set at 1, bash happily recurses forever ... that is another bug, am I
> > right?)
> 
> Interesting. I am unable to reproduce that. However yes, that would be
> another bug.

Filed as bug 1274553.