From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 72E053858C39 for ; Tue, 28 Dec 2021 02:46:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72E053858C39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52c.google.com with SMTP id b13so68282345edd.8 for ; Mon, 27 Dec 2021 18:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=j6M7YJpeWS1DbHv8u/GzfJww7Og6gOZ7BsgxkfW2BEU=; b=Pzq3jXiO5Zi7FpLbZDyQ4Pv0ThdXcsbDkSl+xV6mFh8G6pYQs2kafoduc5nEMuHsVI s43GaiEcM+Cpf+zELCYJuFEE6QYtsnlJAXq7aQZEM7DshnoT9uvg/eGK06G89NFan2qz 5YlJvLttluevlrkapeyLYQWbjInP1YI+KdpJA+Ph5PmebsXF6ny3PKpdIAYUoyOov3UX 8gjgHIdDmyjp4Lmg6NV3HpkY/ati2KfAfA9ZZS8e581RJRRCVNwu7nDYnIMhMGNWasUL ZIeVYRuG2Nmq0OPdzos2vUTDsUCbZ66dtScnJhBbuK+cV6cq5Q5a+7Leb1WUXuMFuOOM QMMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=j6M7YJpeWS1DbHv8u/GzfJww7Og6gOZ7BsgxkfW2BEU=; b=bQxwTQ+ARhj0q9iq37bbATLzcmwWmibku2NKS3txjuhxs2U6QEtO7Hf0BWLgibXKxl q/HOijI6NGkdE7QlAbUV1/CJXc7cJrwIlNreVK/2Fa5F4f5ezDgla7rn3kyfvZU9+GUc dKXabNuYrTtcFiAyMvIZ/EIU+Te5M35NhzJUnSy19x80acOE75xzBwAeiYO9smWW5KzZ jKaKkDk2M/43ZJJ/2/mrzoyk7Mh9zhSOVV57zQ1DwFF72+lWOAxa72jO6jT3k3bqcDqM ABZHoL6yjJiYQ2NXUxM+NtlI7EdpeLrE582krlcCF9HNuLBIfAw4hfyC7khHP8U+4LLc Gj9g== X-Gm-Message-State: AOAM532yfgacX+1NVHg9ZJZ+yNde2yuyfxHbR7FIWki/UbkPKpiqMl6s KZ/flNVPPCd0hs4P+rC17Is= X-Google-Smtp-Source: ABdhPJypTn5ckU5QMMCbF+o/AkIQLvCR3AtWi6MllKa4ZBcA34FCA1HW0pG8aKbTIB+LYlfrTzAxSA== X-Received: by 2002:a50:9e6c:: with SMTP id z99mr19008020ede.71.1640659567568; Mon, 27 Dec 2021 18:46:07 -0800 (PST) Received: from [192.168.1.42] (dynamic-adsl-84-220-15-235.clienti.tiscali.it. [84.220.15.235]) by smtp.gmail.com with ESMTPSA id e19sm6735220edu.47.2021.12.27.18.46.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Dec 2021 18:46:07 -0800 (PST) Message-ID: <36f78776-bb14-7a55-3cd8-5ff54d89f6a0@gmail.com> Date: Tue, 28 Dec 2021 03:46:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Signal delivered while blocked Content-Language: it To: David McFarland Cc: cygwin-developers@cygwin.com References: From: Marco Atzeri In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2021 02:46:10 -0000 On 28.12.2021 00:14, David McFarland wrote: > >> Hi Guys, >> >> Some time ago (2017) a Postgres developer reported a signal issue >> not present in older version (2013) >> >> https://sourceware.org/pipermail/cygwin/2017-August/234001.html >> >> For what I can see the issue is still present. >> >> >> Ideas for debugging ? > > I had a look at your program. What seems to be happening is that he > signal thread receives the signal, and uses find_tls to find a thread to > handle it. If this is after a call to sigpermit(), then the mask will > be zero and it will commit to sending the signal to the main thread of > the test program. > > This is done without any lock, so the main thread can now handle an > existing signal, call sigforbid() then usleep(). > > At this point the signal thread can resume, queuing up the next signal, > and the main thread will pick it up when usleep calls > sig_dispatch_pending, even though the main thread signal mask now > disallows it. > > The old thread ended with a discussion about whether this is even valid > se of sigprocmask(), which didn't seem to be resolved. Anyone have any > thoughts on that? Thanks David, I am not an expert in signal, but it seems the program is working as expected on Linux and other platforms and only cygwin is presenting it. I have not anymore a Linux box so I can not check. The test case is not mine, it is coming from Noah Misch, https://www.postgresql.org/message-id/20170811021007.GB3623941%40rfd.leadboat.com that also reported in 2017 on the Cygwin mailing list and the discussion was recently revived on the Postgres dev list https://www.postgresql.org/message-id/20210622064212.GA1367859@rfd.leadboat.com Regards Marco