Messages in this thread | | | Date | Thu, 4 Mar 1999 13:30:59 +0000 (GMT) | From | Tigran Aivazian <> | Subject | Re: 2.2.1: memory corruption and SIGSEGV handlers. |
| |
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/
| |