[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJt8pk9aKO6d66wDAQKM-DB1aQEcQXSohamc4pNM_gVyVqP==w@mail.gmail.com>
Date: Wed, 9 Sep 2026 18:00:22 +0200
From: Pavel Labath <labath@...gle.com>
To: John Scott <jscott@...teo.net>
Cc: libc-coord@...ts.openwall.com
Subject: Re: An async-signal-safe way to get thread’s stack
On Wed, 9 Sept 2026 at 17:12, John Scott <jscott@...teo.net> wrote:
> So, regardless of whether the signal handler is using an alternate signal stack, one can access ((ucontext_t *)context)->uc_stack within such a signal handler to obtain a stack_t, which is a structure that shall contain at least the following members describing the stack of the thread which was interrupted:
> > void *ss_sp Stack base or pointer.
> > size_t ss_size Stack size.
> > int ss_flags Flags.
>
> Valid flag values starting with SS_ are defined for XSI systems, and I think implementations are allowed to expose other SS_ constants too.
>
> Maybe this gets you somewhere 🤷
Unfortunately, it doesn't work this way, at least not on Linux. It
can't work because the kernel does not track userspace stack
information. This field contains the *alternate* stack information
(which is tracked by the kernel). It is saved here by the kernel so
that it can be restored when the signal handler returns
(SS_AUTODISARM). So, in a signal handler, this does not refer to the
stack of the interrupted code, but to the stack where the signal
handler is executing. This is also why I'm not that worried about
alternate stacks, as one can read that information from this field
(with some caveats regarding nested signals).
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.
