[PATCH 0/2] Fix SIGSEGV handler and other synchronous signals

Vratislav Podzimek vpodzime at redhat.com
Tue Sep 16 06:51:21 UTC 2014


On Mon, 2014-09-15 at 11:19 -0400, David Shea wrote:
> On 09/15/2014 10:03 AM, Vratislav Podzimek wrote:
> > On Mon, 2014-09-15 at 09:27 -0400, David Shea wrote:
> >> On 09/15/2014 02:24 AM, Vratislav Podzimek wrote:
> >>> On Fri, 2014-09-12 at 16:12 -0400, Chris Lumens wrote:
> >>>>> Ever noticed that the SIGSEGV handler never actually gets called?
> >>>> Now that you mention it, yeah.  I was curious what was happening there.
> >>> I've seen it being called, resulting in a nother SIGSEGV. :)
> >>>
> >>> Looks good to me as well.
> >>>
> >> Oh wow, really? In light of that, I think it'd be a good idea to undo
> >> the part where I took out
> >>
> >> -    signal(SIGSEGV, SIG_DFL); /* back to default */
> >>
> >> Since if we keep that in, a crash in the signal handler will just crash anaconda all the way instead of getting stuck in a signal handler loop. And I guess I should add a comment to that effect.
> > Maybe, but with that line in, it got stuck in sigsegv-loop. Do you think
> > that would work with your changes? I think the reason for that loop was
> > Python code doing things you really shouldn't/cannot do in a SIGSEGV
> > handler.
> >
> 
> 
> The python code does make it weirder, since the actual signal handler is 
> in the python interpreter and by the time you get to the code you 
> installed as a handler, you're no longer actually in a signal handler 
> from the view of the kernel. By putting everything in C, resetting to 
> SIG_DFL matters a lot less. I asked in #devel about what happens to 
> signals triggered by signal handlers, since I would have thought that 
> installing it without SA_NODEFER would cause SIGSEGV to be blocked 
> within the handler, and it turns out the kernel actually forces SIGSEGV 
> to be re-delivered by unblocking the signal and resetting the handler to 
> SIG_DFL.
> 
> So crashes in the signal handler really crash, which is what we want, 
> but as far as making the desired behavior explicit, I think we could 
> install the handler with SA_NODEFER | SA_RESETHAND. The handler exits at 
> the end, so it's in effect a one-shot handler already, and having 
> SA_NODEFER makes SIGSEGV explicitly not blocked during handling of SIGSEGV.
That makes sense to me. Thanks for the additional effort spent on this.
And don't forget to add a comment explaining those flags.

-- 
Vratislav Podzimek

Anaconda Rider | RHCE | Red Hat, Inc. | Brno - Czech Republic




More information about the anaconda-patches mailing list