On 4/12/19 12:12 PM, Andrew Church wrote:
>> This recursive function causes bash to segfault:
>>
>> $ re() { t=$((t+1)); if [[ $t -gt 8000000 ]]; then echo foo; return;
>> fi; re; }; re
>> Segmentation fault (core dumped)
>>
>> Ideally Bash ought to run out of memory before this fails. But an
>> acceptable solution could also be to say 'stack overflow'.
>
> That's exactly what bash is saying there. I'm not sure what (if
> anything) POSIX specifies for stack overflow behavior, but at least on
> Linux, stack overflow raises SIGSEGV:SIGSEGV on stack overflow IS the POSIX-specified behavior. However, just because POSIX requires SIGSEGV on stack overflow does not imply that it requires bash to terminate with a core dump - it is also acceptable if bash wanted to catch SIGSEGV (via a sigaltstack() handler, since the overflowed stack itself can't be used), and then gracefully terminate with a saner error message about stack overflow. In fact, GNU libsigsegv makes it very easy to write such a handler, and several other GNU programs (at least gawk and m4 come to mind) that can have user-triggered stack-overflow use it for that purpose. (If you write your program carefully enough, it's also possible to resume operation rather than terminate when detecting stack overflow - but _that_ task is very difficult to do as you MUST write your code in such a way that the stack overflow is only possible in code under your control rather than in the middle of a libc function call that might strand a locked resource. Neither gawk nor m4 are up to the task, and I seriously doubt bash is any better suited for the challenge) But just because it is okay to use libsigsegv to handle stack overflow gracefully doesn't necessarily mean that Chet wants to do so; particularly if no one contributes the patch to wire it in. And bash has the additional complication of the 'trap' builtin - whatever handling you do for SIGSEGV on stack overflow must not interfere with user-installed trap handlers for SEGV operating sanely when there is not stack overflow. So in the meantime, the core dump is the best you'll get. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
