Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Feb 2024 14:00:33 +0300
From: Valery Ushakov <>
To: Rich Felker <>
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.



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.