[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e6a3b6df6219c9677625afe1d55b37c4b65f6b4f.camel@posteo.net>
Date: Wed, 09 Sep 2026 17:03:14 +0000
From: John Scott <jscott@...teo.net>
To: libc-coord@...ts.openwall.com
Subject: Re: An async-signal-safe way to get
thread’s stack
Pavel Labath wrote:
> 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.
If this were the sole hurdle, it'd seem that this structure member would help:
> ucontext_t *uc_link Pointer to the context that is resumed when this context returns.
i.e. if you have access to some ucontext_t corresponding to the signal handler's context, (ucontext_t *)->uc_link could refer to the context of the interrupted thread after all.
But...
> 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.
It is a dead end on Linux after all. I tried to experiment with this (sample code attached) but the base of the stack is always recorded as a NULL pointer and the stack having zero size. The more you know...
View attachment "ucontext_siginfo.c" of type "text/x-csrc" (1209 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (412 bytes)
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.
