[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdM00UVZYqj_Hfgc@snips.stderr.spb.ru>
Date: Mon, 19 Feb 2024 14:00:33 +0300
From: Valery Ushakov <uwe@...err.spb.ru>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Re: Not sure how to debug this one.
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
