Re: [musl] Re: Not sure how to debug this one.

[Valery Ushakov <uwe@stderr.spb.ru>]

On Sun, Feb 18, 2024 at 15:33:06 -0500, Rich Felker wrote:

> > Restoring the context in siglongjmp should not be a problem per-se.
> > NetBSD libc does that and the example code doesn't crash there (quick
> > unscientific test on a ppc that I happen to have a terminal open on).
> > But then NetBSD libc doesn't bother to carefully factor that code to
> > minimize the need for MD asm.
> > 
> > Thanks, and sorry for the noise.
> 
> If you restore the signal mask from the returning context rather than
> in the returned-to context, there's always the possibility of stack
> overflow; in the worst case, this happens on the sigaltstack where
> you're specifically taking measures to avoid stack overflow being a
> fatal error. The test program is artificial, but the real-world way
> this would happen is getting a flood of signals like SIGINT or SIGTSTP
> or something coming in faster than you can respond to them, so that
> every time you try to return via siglongjmp, you actually consume
> another stack frame on the signal stack.
> 
> If NetBSD didn't crash, maybe it just has a much larger default stack
> size limit? Or maybe they reload sp before calling sigprocmask? That
> would work too, but the reason musl doesn't do it that way is that our
> setjmp/longjmp are compatible with an old ABI where there is no extra
> space in the jmp_buf for sigjmp_buf stuff.

As luck would have it, powerpc was doing the right thing.  We filed a
bug to fix the arches that don't.

Thanks!

-uwe