Hi folks,
I have a probably louzy question regarding sigaction() behaviour when an
alternate signal stack is used: it seems that I can not get the user
stack reference in the ucontext_t stack context ; ie. the uc_stack
member contains reference of the alternate signal stack, not the stack
that was used before the crash.
Is this is a normal behaviour ? Is there a way to retrieve the original
user's stack inside the signal callback ?
The example given below demonstrates the issue:
top of stack==0x7fffff3d7000, alternative_stack==0x501010
SEGV==0x7fffff3d6ff8; sp==0x501010; current stack is the alternate stack
It is obvious that the SEGV was a stack overflow: the si_addr address is
just on the page below the stack limit.
On Mon, 2007-01-22 at 09:57 +0100, Xavier Roche wrote:
> Hi folks,
>
> I have a probably louzy question regarding sigaction() behaviour when an
> alternate signal stack is used: it seems that I can not get the user
> stack reference in the ucontext_t stack context ; ie. the uc_stack
> member contains reference of the alternate signal stack, not the stack
> that was used before the crash.
>
> Is this is a normal behaviour ? Is there a way to retrieve the original
> user's stack inside the signal callback ?
>
> The example given below demonstrates the issue:
> top of stack==0x7fffff3d7000, alternative_stack==0x501010
> SEGV==0x7fffff3d6ff8; sp==0x501010; current stack is the alternate stack
>
> It is obvious that the SEGV was a stack overflow: the si_addr address is
> just on the page below the stack limit.
POSIX says:
"the third argument can be cast to a pointer to an object of type
ucontext_t to refer to the receiving thread's context that was
interrupted when the signal was delivered."
so if uc_stack doesn't point to the stack in use immediately prior to
signal generation, this is a bug.
(In theory I should be able to pass the ucontext_t supplied to the
signal handler to setcontext() and resume execution exactly where I left
off -- glibc's refusal to support kernel-generated ucontexts gets in the
way of this, but the point still stands.)
I have no idea who to bother about i386 signal delivery, though. (And I
suspect this bug has probably been copied to other architectures as
well.)
--
Nicholas Miell <[email protected]>
Nicholas Miell wrote:
> so if uc_stack doesn't point to the stack in use immediately prior to
> signal generation, this is a bug.
Looking at arch/i386/kernel/signal.c (and others) inside
setup_rt_frame(), the problem is pretty obvious:
err |= __put_user(current->sas_ss_sp, &frame_user->uc.uc_stack.ss_sp);
err |= __put_user(sas_ss_flags(regs->esp),
&frame->uc.uc_stack.ss_flags);
err |= __put_user(current->sas_ss_size, &frame_user->uc.uc_stack.ss_size);
And of course, the ss_sp is NULL when no alternative stack is used.
Seems definitively a bug.
However, my reading of include/linux/sched.h and thread_info.h did not
enlighten me on the way to get the original thread's stack base and size.