DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52EEP8uc1432677 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 52EEP8uc1432677 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=e6L+rcXK X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CEDE385773C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1741962307; bh=52cK/dX2hSilaGkpEqUVfjxu2jcaccfKqrgCtAIguHI=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=e6L+rcXKb3fheL54x+f0kEhL4d6nhjYhALMkFqp6LhDzohuFiOauJFsbXyyD3B9wP UDAv09qXOB1GUrBVhayUUyhzOaJvH7VW48C0oMySjBXlpg+tfL5cjZjqfXYW8uWiL7 59Ml+ro/3e7gvfFA/WKms14Q//RtuhlYhV2RsJIk= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C9C43857831 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2C9C43857831 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741962275; cv=none; b=NK9ild6z3GXafZKaikEM0a+2FWadOur7+gLeqXwoK43efri+boYJouq7V52XoPGyzT5fS35ZqZ9phFYmUt2EK3Wt52GEklPuaDercNjjFlXEJToocTbd8V46/Vdq17KY24n4RXVt5mf2YlUTywKXWl8O7Ba7FH6Uz1zPkmm/IEw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741962275; c=relaxed/simple; bh=iV05WysH0zhTDLWQ2so7I4ja9Xl5xK6iLnQWOx7f6FU=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=ppGvZXtXoZ8jJRAen+VgbJ4bNE2nD/2hEOTQJjZm9fAR2yvfcvGsvgXVT4eRUkXFIUAQJPpsxV4NlBfI9tFqfBV7PM6WFosZxeQ7HHBb4SHG9khNvAFlozoty11KvykAlcQEim+wKkzIkm0L/8Lp7KLEQZJXZ8QJ1C3gg6JkE1M= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C9C43857831 Date: Fri, 14 Mar 2025 23:24:32 +0900 To: cygwin AT cygwin DOT com Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used Message-Id: <20250314232432.c894c2eb6a3799f89d492ac2@nifty.ne.jp> In-Reply-To: References: <20250313204252 DOT e340f0de50838f161b0e8323 AT nifty DOT ne DOT jp> <20250313213148 DOT 6c2cb65f5e692005f28d3d2c AT nifty DOT ne DOT jp> <20250314081236 DOT bbdb1da7d746745925cdc752 AT nifty DOT ne DOT jp> <20250314125632 DOT dc61b5b087eb43d67228cc92 AT nifty DOT ne DOT jp> <20250314203548 DOT 878211c61777a8d99b7de7ea AT nifty DOT ne DOT jp> <20250314215242 DOT 8ef1214b77ccc472139b3a3a AT nifty DOT ne DOT jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 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: Takashi Yano via Cygwin Reply-To: Takashi Yano 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 Fri, 14 Mar 2025 15:18:45 +0100 Corinna Vinschen wrote: > On Mar 14 21:52, Takashi Yano via Cygwin wrote: > > On Fri, 14 Mar 2025 13:19:28 +0100 > > Corinna Vinschen wrote: > > > On Mar 14 20:35, Takashi Yano via Cygwin wrote: > > > > On Fri, 14 Mar 2025 11:01:25 +0100 > > > > Corinna Vinschen wrote: > > > > > I don't think so. I was mulling in circles over this tonight > > > > > (don't ask me how I slept!) and came to the same conclusion. > > > > > But here's the problem: > > > > > > > > > > I'm simply not 100% sure. > > > > > > > > > > What concerns me is that stackptr points beyond stack if the stack > > > > > is full (i.e., sigdelayed + return address). > > > > > > > > > > That was what happened before I applied a942476236b5: stackptr was > > > > > incremented until it pointed at _cygtls::initialized, and eventually it > > > > > overwrote it. Fortunately, that stopped further incrementing due to the > > > > > isinitialized() test. > > > > > > > > > > So, if there *is* a twisted situation which results in pushing another > > > > > return address onto the stack, a stack size of 2 would again result in > > > > > initialized being overwritten. So I wonder if we should keep kind of > > > > > an airbag for an unusual situation. Plus trying to keep stackptr inside > > > > > stack even if it's full. So that stackptr never grows into initialized: > > > > > > > > > > #define TLS_STACK_SIZE 5 > > > > > > > > > > and > > > > > > > > > > void push (__tlsstack_t addr) > > > > > { > > > > > if (stackptr < (__tlsstack_t *) &initialized) > > > > > *stackptr++ = (__tlsstack_t) addr; > > > > > } > > > > > > > > > > What do you think? > > > > > > > > Yeah. We do not have to minimize the stack space at the cost of > > > > taking risks. > > > > > > > > One more thing. I am also concerned that pop() lacks a guard. > > > > If pop() calls when stack is empty, then push() destroys the > > > > stackptr pointer value. > > > > > > Good point. I attach a new proposal. It also doesn't check against > > > &initialized (becasue that doesn't avoid an overflow into initialized, > > > but against the last slot of the stack. This also moves pop into > > > the C++ code and drops its assembler counterpart. > > > > > > Ok? > > > > LGTM. Thanks! > > Pushed. I didn't create a test release, because I was sure you > would push your other signal patches ASAP anyway. Yeah. pls check: https://cygwin.com/pipermail/cygwin-patches/2025q1/013496.html -- Takashi Yano -- 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