DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 54U8m7Kp1008685 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 54U8m7Kp1008685 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=k3O0pHUE X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 973C03857BA0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1748594885; bh=u6A+SWf/57kr8M1tg3tenPxrQHMDUWTfPjj7sbBoK3U=; 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=k3O0pHUEBsoTEA9lOi/cQbaoAdZThJkFiCsDyD5VS/aAoxYxN1WpGUsbyOzIAPutv TJukGktQ+ijN+1GG/duKJMMUD7u+xJuAG0+wyewXdsCBDKCPYuhv76c5lRSCdpN36q nf40rZidifodEedgV/RJQ10Z17pKfzt+1ilDWsXw= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DFE7385840D ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7DFE7385840D ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1748594855; cv=none; b=b/dQ4ZT+KNqJ60lwkF5RIBVK13WDct5tQKSQfRA7UsvxivM0RDFuKCBpvToG/piyVid6P8dJJ4fUHiZh3eVgf8ut08o1kcx9j9wenHtESjOSX9/efNUx3I8Chyzu5f7V4dC/CWZO9LgNoDMlL9N/5x94llJlQ2PlSG4CNq+WkKU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1748594855; c=relaxed/simple; bh=OOPWvY82QJXP0j6KMTWjgBpN8Dg/4TrmkOuxtwo51dQ=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=QLAGreQMUawozXT+sD45MMYmJjdQL+16CVYRncNCZwlEtC51/W7W7T771aPargEbdyJfOqJ6ctAi0xBrZkUBYPTLhzimpFooA0THHcJQ9rZLvvqh/VbKSneMNI4zaVAysCIhurAVYvxC/Kqusp+PCG9XLc3tbsaKv8hFLxTyG3A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7DFE7385840D Date: Fri, 30 May 2025 17:47:30 +0900 To: cygwin AT cygwin DOT com Subject: Re: Crash or hang if SIGSEGV+SIGALRM are nested Message-Id: <20250530174730.7475a800c9f189b21ee0646e@nifty.ne.jp> In-Reply-To: <32cf9316-3e97-7fab-f975-851c3dfc25b9@t-online.de> References: <20250528215707 DOT ddb72fb28122c3ed07da8c5b AT nifty DOT ne DOT jp> <20250529102846 DOT 8144f502c3f17decbe6700c1 AT nifty DOT ne DOT jp> <76940263-49e8-1b4a-17f2-11f5545014ab AT t-online DOT de> <20250530015410 DOT e8c4808c7947682b3309fbe7 AT nifty DOT ne DOT jp> <32cf9316-3e97-7fab-f975-851c3dfc25b9 AT t-online DOT de> 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 Thu, 29 May 2025 20:01:31 +0200 Christian Franke wrote: > Takashi Yano via Cygwin wrote: > > On Thu, 29 May 2025 17:32:19 +0200 > > Christian Franke wrote: > > ... > >> I still don't fully understand why a SIGSEGV triggered by an instruction > >> could interrupt a SIGALRM handler. > >> https://sourceware.org/pipermail/cygwin/2025-May/258145.html > >> > >> I guess such behavior is valid from the POSIX point of view, but it is > >> at least unexpected. If the SIGALRM handler is already running, it > >> should have interrupted the thread such that the instruction triggering > >> the segfault is not executed until the SIGALRM handler returns. > > I try to explain what is happing using the figure below. > > > > <<<<<< Main thread >>>>>> < Signal Thread > > > SIGNAL > > main() handler1() handler2() QUEUE wait_sig() > > | . . | | > > | . . ALRM | | > > +----------------------------------------->| ALRM | > > | . . SEGV +--------->| > > X----------------------------------------->| | > > | . arm ALRM | | > > +----------+ <----------------------------------------+ > > | . | SEGV | > > | . +--------->| > > | . | | > > | . arm SEGV | | > > +----------+ <-----------------------------+ > > . | | | > > longjmp() | | | > > +---------------------+ | | > > | . . | | > > | . . | | > > > > The point is the exception handler does not arm SIGSEGV handler > > directly. It just pushes the SIGSEGV into the signal queue. > > The signal thread reads the queue and process it asynchronously, > > and arms the handler(). > > > > I see. Thanks for nice explanation! > > I created an issue at stress-ng upstream because at least the --mprotect > test is affected: > https://github.com/ColinIanKing/stress-ng/issues/529 Thanks! BTW, do you think this is the right thing? https://github.com/RISCV-Tools/stress-ng/commit/bf24393357cde137bb8e7b38f917f565946199fd I think the patch should set SIGSEGV mask on SIGALRM. -- 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