RE: Signal 11 on Process Termination - Update

RE: Signal 11 on Process Termination - Update

[Phil Thompson]

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:Phil.Thompson@pace.co.uk]
> Sent: 04 September 2001 16:52
> To: 'linux-mips@oss.sgi.com'
> 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
> 

Re: Signal 11 on Process Termination - Update

[Atsushi Nemoto]

>>>>> On Tue, 4 Sep 2001 18:48:33 +0100 , Phil Thompson <Phil.Thompson@pace.co.uk> 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

RE: Signal 11 on Process Termination - Update

[Phil Thompson]

This fixed the problem - many thanks.

Ralf - is this patch going to be applied (the current CVS seems unusable
without it)?

Phil

> -----Original Message-----
> From: Atsushi Nemoto [mailto:nemoto@toshiba-tops.co.jp]
> Sent: 05 September 2001 01:30
> To: Phil.Thompson@pace.co.uk
> Cc: linux-mips@oss.sgi.com
> Subject: Re: Signal 11 on Process Termination - Update
> 
> 
> >>>>> On Tue, 4 Sep 2001 18:48:33 +0100 , Phil Thompson 
> <Phil.Thompson@pace.co.uk> 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
> 

Re: Signal 11 on Process Termination - Update

[Ralf Baechle]

On Wed, Sep 05, 2001 at 11:07:58AM +0100, Phil Thompson wrote:

> This fixed the problem - many thanks.
> 
> Ralf - is this patch going to be applied (the current CVS seems unusable
> without it)?

I've applied a different patch to CVS.

I've got other different problems with the current CVS; the 32-bit kernel
is very unreliable for me on 32-bit machines.

  Ralf

Re: Signal 11 on Process Termination - Update

[Pete Popov]

Ralf Baechle wrote:
> On Wed, Sep 05, 2001 at 11:07:58AM +0100, Phil Thompson wrote:
> 
> 
>>This fixed the problem - many thanks.
>>
>>Ralf - is this patch going to be applied (the current CVS seems unusable
>>without it)?
>>
> 
> I've applied a different patch to CVS.
> 
> I've got other different problems with the current CVS; the 32-bit kernel
> is very unreliable for me on 32-bit machines.

That's my experience as well, just FYI.

Pete