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?
> -----Original Message-----
> From: Phil Thompson [mailto:Phil.Thompson@pace.co.uk]
> Sent: 04 September 2001 16:52
> To: 'email@example.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
> Any suggestions gratefully received.