Description of problem: When in bash script is function which calls itself repeatedly (recursion) it causes bash to crash. Version-Release number of selected component (if applicable): bash-3.1-16.1 How reproducible: always Steps to Reproduce: 1. sh bash-kill.sh Actual results: dhcp-lab-198 mounting # time sh bash-kill.sh Segmentation fault real 0m8.122s user 0m8.005s sys 0m0.088s Expected results: dhcp-lab-198 mounting # time sh bash-kill.sh + as a bonus 100 % CPU usage forever
Created attachment 295437 [details] testcase causing bash to crash
Well, that's what unbounded recursion does in C as well. ksh solves this by limiting the recursion depth (to something like 4096, which is not many). We could limit it as well, but that won't give the results you expect. To get that, bash would have to support tail recursion, and I guess that would be quite an overkill for a shell.
Limiting it to some random number seems to me dumb, I don't see any number being the Right One. User defined MAX_RECURSION=Int seems to me bad for debugging in general. The saner solution seems to me mentioned tail recursion. When there's no agreement in upstream on expected behavior you can always close it with note in docs that "this case does not have expected result", but that's kinda coward, but viable.
http://lists.gnu.org/archive/html/bug-bash/2008-03/msg00017.html
> http://lists.gnu.org/archive/html/bug-bash/2008-03/msg00005.html > > ...including libsigsegv as an option for making stack overflow detection > result in nicer output than a crash. What about this? It's in Fedora.
Well, we don't want to diverge from upstream, so I'll leave this up to them.