Re: Segfault after many stackframes

[Eric Blake]

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