On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
> Theoretically, a small update to sigdelayed() would fix the issue: ather
> then poing the original IP from the signal stack after calling the

Make that:

  Theoretically, a small update to sigdelayed() would fix the issue:
  *R*ather then po*p*ing the original IP from the signal stack after
  calling the
  
> handler, it should pop the IP prior to calling the handler.  That would
> avoid filling up the signal stack when long-jumping out of the signal
> handler.  It should store the IP in one of the callee-saved registers.
> %r13 is unused in sigdelayed so far.
> 
> However, even if we do this, there's still the problem that sigdelayed()
> itself takes space on the stack.  If you longjmp/setcontext out of the
> handler, the thread's normal stack will fill up with dead storage of the
> sigdelayed() function, and there's no way out of this trap.  We can't
> restore the stack before the handler returns.
> 
> So either way, at one point you get a stack overflow one way or the
> other.
> 
> The signal stack overflow is actually rather harmless in comparison
> to a real stack overflow.
> 
> If you have any idea how to avoid the real stack overflow, I'd be
> all ears.

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Reply via email to