Re: determining the stack bounds

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> > 
> > On the other hand, POSIX states for sigaction() that the handler's "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."

> |
> |> The receiving thread may currently be in the alternate stack, but
> |> the signal was delivered when the thread was still in the primary
> stack.  So
> |> maybe we should file this as a bug with the kernel folks, and hope that a
> |> future version of Linux change uc_stack to supply the information we
> want.
> |> After all, we don't need uc_stack to learn about the current
> (alternate) stack;
> |> we can use sigaltstack() for that.
> |
> | I think you are misunderstanding things, and there is no Linux kernel
> bug here.
> 
> Where would I even go to ask a Linux developer this question?

I've tested on another platform.  On Solaris 8, uc_stack is (IMHO properly) 
pointing to the primary stack, even though the handler is executing on the 
alternate stack.  So on Solaris, the existing c-stack module correctly 
distinguishes between stack overflow and true SEGV, and there is no need for 
any mincore()-like API for determining which memory is mapped.

But what was weird on Solaris - when running the program natively, the stack 
overflow is detected.  But when running under gdb 5.3 (yes, the machine's copy 
of gdb is 6 years old), even though the ucontext_t is properly set, the fact 
that the program is run as an inferior and gdb is intercepting signals means 
that the siginfo_t structure reported a si_code of 0 and lost the si_addr 
information; and so the inferior program reported program error rather than 
stack overflow.  Probably a gdb bug, and hopefully one that has been fixed in 
the meantime.

If Linux wants to follow Solaris' lead, then it's looking more and more like a 
Linux kernel bug that uc_stack isn't useful.  Again, anyone know how to report 
something like that?

-- 
Eric Blake