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