Re: 2.2.1: memory corruption and SIGSEGV handlers.

Tigran Aivazian (tigran@SCO.com)
Thu, 4 Mar 1999 13:30:59 +0000 (GMT)

My #0.02 worth - I agree with Mark's finding in the Single UNIX v2 spec.
It seems logical and reasonable. In fact, I think essentially, that was
what Mark suggested in our chat here even before he checked the specs,
(which suggests that specs *are* written by human beings with some common
sense :) ).

I did not have time to try it under 2.2.2 as Ingo suggested - will try it
this evening probably. Also, Pavel Machek is reporting that he sees no
problem under 2.2.2UP so the actual corruption is either something
non-trivial or fixed in 2.2.2.

Regards,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.aivazian.demon.co.uk

On Mon, 1 Mar 1999, Mark Hemment wrote:

> Richard,
>
> > > > So you are saying that setup_frame() should reserve enough signal
> > > > stack-space to use the default handler if the signal stack grows
> > > > beyond limits? Let's look at the case of root where there is no
> > > > getrlimit set.
> > >
> > > No. The default action for SEGV (the signal we are interested here),
> > > is to drop core. This doesn't require any user-stack space (just a call
> > > to do_exit()).
> > >
> >
> > But isn't that call on the signal stack?
>
> No.
> do_exit() would be called from the kernel's signal delivery code (in fact
> it already is when the installed handler is SIG_DFL). All carries on
> running in kernel space, there is no return to user-space and so no need
> to use the user's stack.
>
> Mark
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/