DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52CFguDt3859189 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 52CFguDt3859189 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=h40tJ7mI X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 324C03858427 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1741794175; bh=TmV/hUuMduzIW4RRLQsreu7xMOMDOwhM1sdDTLmC9oI=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=h40tJ7mIozK8iiZJuVIdJ6mdtPLkkJ25Nr4BVejWyJ1MjTRPzXzlGufUivS8TJqoT JpLUCUvsuqjpcdxRJfBbV36A/IELfqBF+ZqVcfvpYEF+n31snZZBtot7vJ59QlSfFH IO878JluyCKFzEnEeb+6N///fBkXixmK2tsB7jmM= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A68FE385843B Date: Wed, 12 Mar 2025 16:39:49 +0100 To: cygwin AT cygwin DOT com Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: <373993a3-9f0f-9750-60a0-950f83b3b0b5 AT t-online DOT de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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