sigaltstack with threads
Doug Rabson
dfr at nlsystems.com
Sat Dec 27 07:06:08 PST 2003
On Sat, 2003-12-27 at 14:56, Daniel Eischen wrote:
> On Sat, 27 Dec 2003, Doug Rabson wrote:
>
> > I've been using my festive spare time in porting the excellent valgrind
> > error checker to FreeBSD. While working through the complex way that
> > valgrind deals with signals, I noticed a tricky problem.
> >
> > When a signal stack is installed in FreeBSD, the stack location is
> > recorded in the per-process state (p_sigstk to be exact). This stack is
> > used in sendsig() for signals handlers which asked for SA_ONSTACK. This
> > is a problem for valgrind since it uses two threads (I use the thr_*
> > syscalls for this purpose).
> >
> > The main thread does most of the work and wants to take a selection of
> > signals (SIGSEGV, SIGBUS etc) on a signal stack allocated for the
> > purpose - all other signals are blocked.
> >
> > The other thread is used for executing blocking syscalls (actually there
> > can be more than one of these for pthread programs but I don't have that
> > working yet). This syscall thread runs with something like the debugged
> > program's normal signal mask so most of those signals get routed to the
> > syscall thread. The main problem is that the syscall thread wants to
> > take the signals on its normal stack but it can't use a different
> > setting for sigaltstack.
> >
> > It seems to me that sigaltstack needs to be per-thread state, not
> > per-process state otherwise it is essentially useless for threaded
> > programs. As far as I can make out, this is the behaviour for Linux
> > threads created using their clone syscall.
>
> In the '96 POSIX spec, using sigaltstack() in threaded applications
> was undefined. The new (SUSv3 200[123]?) POSIX spec allows this
> but says "Use of this function by library threads that are not bound
> to kernel-scheduled entities results in undefined behavior". I think
> that allows you to make it per-thread, but what behavior do we
> want when there are multiple threads in a KSE/KSEG? Should it be
> per KSE or KSEG?
I think that if its supported at all in threaded programs, it must be
per-thread state otherwise you can't prevent two different threads
colliding on the same signal stack. I can't quite see how this maps to
KSE/KSEG since I only have the most hazy model of that stuff in my head
right now.
Anyway, I've worked around things by not setting SA_ONSTACK for the
handlers that I want to run on the thread stack.
More information about the freebsd-arch
mailing list