DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52D9fVU0059106 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 52D9fVU0059106 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=xY4CuXSc X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F4233857B96 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1741858889; bh=OvKrlaQWbCMtPtrtzml2sMaaWm7efaydiR2GNG83YaY=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=xY4CuXScq0PCeARf9WArwDZerlk6YhKOGEN9hZlCS58NMoev0L/gubaJaHKpdCqKL kzI4qstPfKsuD3mzqXY0QVrP9RsQKTW49BQQXZUi9dlyzzh/HK0OqLJTJ0mOTuDec8 M26S3d8D37JUC8DyhXdTFYbDl3Mybsa9u+v6OgvM= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB4833858D33 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DB4833858D33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741858857; cv=none; b=HXuE08ia5gCXHQg85OBbEBMSI27Hn9Px22uuNJ5DaV0kabcBVOl4Z0MPV7tMtSlCWWgmxgsB2dq/R9fu3qInQsR2jKmA883x0oYgrSGyvygWehTvo083CI3uIaZdp72a4AoTHtr5qPewrPkTlo0uOCyl958ZgA0xstQbDTUyT1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741858857; c=relaxed/simple; bh=wuUMfjNUtNWdkSeE+t4bGgq5hD18Z1zn2RaYouC0jSM=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=gwTCN7Ge5g+zc4+NUwrmwBDfiB/XcsNHr24dPlIyJwGBpQ5x8U4iFJOcVFeijQXuj/ZzpKmQ+D7wsq+wMBNLyr6EB8GEKQNhpi+ghQYRL7YLzUY2VFNuYM6VsC+uK/LPBJDSEUWzeHfj3VHhlJPsscqDqR8IuaMxUYN7MAXSvHw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB4833858D33 Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used To: cygwin AT cygwin DOT com References:

<373993a3-9f0f-9750-60a0-950f83b3b0b5 AT t-online DOT de> Message-ID: Date: Thu, 13 Mar 2025 10:40:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 SeaMonkey/2.53.20 MIME-Version: 1.0 In-Reply-To: X-TOI-EXPURGATEID: 150726::1741858849-6EFFB594-7DEDBB8C/0/0 CLEAN NORMAL X-TOI-MSGID: 12f7863b-4d55-4dd3-af5e-c1a056b1e713 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: Christian Franke via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Christian Franke Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Corinna Vinschen via Cygwin wrote: > On Mar 12 17:06, Corinna Vinschen via Cygwin wrote: >> On Mar 12 16:30, Corinna Vinschen via Cygwin wrote: >>> On Mar 11 12:32, Christian Franke via Cygwin wrote: >>>> The attached testcase should test the following use cases of setcontext: >>>> - call from regular user space >>>> - call from a signal handler interrupting user space >>>> - call from a signal handler interrupting a system call >>>> >>>> It works as expected ... until the signal count reaches 256. Then signals >>>> are again only delivered from inside of a system call. >>>> [...] >>>> Interesting... Hmm... is there some 8-bit counter which overflows and then >>>> stucks at 0xff or 0x00? >>> It's a kind of stack overflow. Kind of, because it's not the normal >>> thread stack, but a special signal stack in the _cygtls area. >>> >>> When interrupting a running thread to call a signal handler, the context >>> of the thread is changed to restart execution in an assembler function >>> called sigdelayed(). The original IP of the thread is pushed on the >>> aforementioned signal stack. Sigdelayed() calls the signal handler. On >>> return it pops the original IP from the signal stack and continues the >>> thread. >>> >>> Now guess what happens if the signal handler bails out with longjmp or >>> setcontext/swapcontext. >>> >>> The signal handler never returns to the sigdelayed() function, the >>> original address is never poped from the signal stack, and the signal >>> stack has a max. size of 256 address entries... >>> >>> Theoretically, a small update to sigdelayed() would fix the issue: ather >>> then poing 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. >> Looks like this isn't really a problem with setcontext. It always >> corrects the stack pointer as well. Apparently I haven't thought >> long enough about this. >> >> I have a patch for sigdelayed() in the loop, stay tuned. > Just pushed. Try cygwin-3.6.0-0.430.ga942476236b5 in a bit. Problem does no longer occur. Also tested with 'kill -INT PID && sleep 0.01' in a loop. -- Thanks, Christian -- 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