RE: [libunwind] Signal handlers and unw_resume

[Thomas Hallgren]

Sigh...

I know that you don't like the idea of using the context passed to the
signal handler to initialize the cursor so I'd like to try another
solution with you. Assume the flow that I just outlined (i.e.
unw_getcontext(), unw_init_local(), and some unw_step() calls) but
instead of the unw_resume() at the end, I would call:

void unw_resume_to_sigcontext(unw_cursor_t* curosr, ucontext_t*
sigcontext);

This method would update the sigcontext based on the current state of
the cursor. It would then return without any jump. So when I do a normal
return from the signal handler and the signal frame thus jumps by
restoring the ucontext, I'd end up at the position where the unw_cursor
was at the time when I called the unw_resume_to_sigcontext.

Can you see that function implemented?

Regards,

Thomas Hallgren


> -----Original Message-----
> From: David Mosberger [mailto:address@hidden
> Sent: Monday, August 23, 2004 1:14 PM
> To: Thomas Hallgren
> Cc: address@hidden
> Subject: Re: [libunwind] Signal handlers and unw_resume
> 
> >>>>> On Mon, 23 Aug 2004 11:55:05 +0100, "Thomas Hallgren"
> <address@hidden> said:
> 
>   Thomas> I have a question on doing a unw_resume from within a signal
>   Thomas> handler. I do the following:
> 
>   Thomas> I call unw_getcontext() from within a signal handler
>   Thomas> followed by an unw_init_local() and a number of unw_step()
>   Thomas> calls to take me passed the signal frame and to the point
>   Thomas> where the code was interrupted. After some local processing
>   Thomas> I then call unw_resume() just prior to where the signal
>   Thomas> handler return would be.
> 
>   Thomas> Then it struck me. Using this approach I effectively skip
>   Thomas> any clean-up processing that normally would occur in the
>   Thomas> caller of the signal handler. Is that a problem? Or is it an
>   Thomas> unspoken law that such processing should never occur in a
>   Thomas> well written OS?
> 
> I think it's a can of worms.  Enough so that there is a regular
> setjmp() and a setjmp_unwind() (defined by C++ ABI).  The former
> doesn't do any cleanups, whereas the latter does.  Your situation
> sound similar.
> 
> Note that NPTL takes advantage of C cleanup handlers so the problem is
> not limited to C++ (other other languages with exception handling).
> 
> I suspect it would be safer (but also much slower), to invoke handlers
> if you encounter them during unwinding.
> 
>       --david