Subject: RE: Signal 11 on Process Termination - Update

From: Phil Thompson <[email-masked]>
Date: Tue, 4 Sep 2001 18:48:33 +0100

Apologies for replying to myself...

After a bit more digging I don't think my comments about the
parent/grandparent relationship are correct.

The SIGSEGV is being raised because the access_ok() in setup_frame() in
kernel/signal.c is failing when trying to deliver another signal (SIGALRM or
SIGCHLD in my cases).

Can anybody explain why access_ok() might fail?

Thanks,
Phil

> -----Original Message-----
> From: Phil Thompson [mailto:[email-masked]]
> Sent: 04 September 2001 16:52
> To: [email-masked]'
> Subject: Signal 11 on Process Termination
> 
> 
> I have a propietary board running a copy of HJ's RedHat 7.1. 
> I've recently
> updated from 2.4.5 and old style timer and interrupt code to 
> the latest CVS
> (2.4.8) and new style timer and interrupt code.
> 
> With the new kernel I'm often seeing processes core dumping 
> with signal 11,
> but only under specific conditions. The process that dies is 
> the parent or
> grandparent of a "busy" process - something like a 
> compilation. It seems to
> die as the "busy" process terminates. Two specific examples...
> 
> cron dies after running updatedb, but doesn't dump core. init 
> also dies, and
> does dump core. It dies "in select() at soinit.c:56".
> 
> make dies after running a shell script that does lots of 
> compilation (it's
> actually building lmbench) "in wait4() at soinit.c:56".
> 
> I assume the reference to "soinit.c:56" is bogus.
> 
> If this is a generic problem then somebody else would have 
> raised it by now.
> 
> In which case it's my new timer or interrupt code - but I 
> can't come up with
> an explaination of how changes in that area would cause the 
> problem I am
> seeing.
> 
> Any suggestions gratefully received.
> 
> Thanks,
> Phil
>

---

From: Atsushi Nemoto <[email-masked]>
Date: Wed, 05 Sep 2001 09:30:05 +0900 (JST)

>>>>> On Tue, 4 Sep 2001 18:48:33 +0100 , Phil Thompson <[email-masked]> said:
Phil> The SIGSEGV is being raised because the access_ok() in
Phil> setup_frame() in kernel/signal.c is failing when trying to
Phil> deliver another signal (SIGALRM or SIGCHLD in my cases).

At setup_frame(), sp (regs->regs[29]) is in the kernel kernel stack,
isn't it?

If so, please try a patch for entry.S I posted a couple days ago.

> Subject: Re: segfaults with 2.4.8

Hope this helps.
---
Atsushi Nemoto