From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id t3uFN2xhy2DgKwAAWB0awg (envelope-from ) for ; Thu, 17 Jun 2021 10:51:24 -0400 Received: by simark.ca (Postfix, from userid 112) id D3DB51F163; Thu, 17 Jun 2021 10:51:24 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 69B491E54D for ; Thu, 17 Jun 2021 10:51:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BD21E396AC00 for ; Thu, 17 Jun 2021 14:51:22 +0000 (GMT) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by sourceware.org (Postfix) with ESMTPS id 817B83983C07 for ; Thu, 17 Jun 2021 14:38:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 817B83983C07 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f46.google.com with SMTP id l7-20020a05600c1d07b02901b0e2ebd6deso3849714wms.1 for ; Thu, 17 Jun 2021 07:38:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HbuQelDuabmaQEF9FkP7aduQ1DtOWw/h4IEATc34Buo=; b=Liqvzah6JVFG54OtdA4giTGoqRxxnirsJs8QU9Q+UDZneX78Havx4eLE3dpYVLXk/n Z8vBmJjCX3eaxBUZBly655qnegR3fOxRoqQrz+mNEMin8nFbgXizvGBp/JrL+9sqfkyk 9AR1xd/HgjdYXVNv2z2Kwllny2UOF5PSn2fucCYnkB5MR63QjRqMXbkyVIaQwqKj8Lm4 wEhj2TuB3NCDc1hXZF6EwdQ+F/NcObZd6BWgDBoJNeicKDSCvMNu4sv8lZmz55vmrITL hxzbEe2uoMQk4FnHT+YS48WCwlan61FFrB7eDvxbYGJwoszdR+BkTOHzOioMG+3LbQ51 HajQ== X-Gm-Message-State: AOAM531l6QtLc4FI03xXXHuDer63GavzRXeU69ojAjSHS6rHgSJYMoM1 0kw7PlTrg70Ghjadszrhf+vgGwgmiYzSW1BS X-Google-Smtp-Source: ABdhPJyANA6rBFz5mymx4cf5GrFlAs4LMgSjwpQdX5mfhFOoYdCXXYlThd35Tgcor9Q8x7LEohMfqw== X-Received: by 2002:a05:600c:3555:: with SMTP id i21mr5548897wmq.51.1623940685697; Thu, 17 Jun 2021 07:38:05 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3? ([2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3]) by smtp.gmail.com with ESMTPSA id o7sm5721352wro.76.2021.06.17.07.38.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 07:38:04 -0700 (PDT) Subject: Re: [PATCH 0/4] Introduce scoped_ignore_signal & make it thread safe From: Pedro Alves To: John Baldwin , gdb-patches@sourceware.org References: <20210615111429.1879286-1-pedro@palves.net> Message-ID: <7f678d4a-b015-655f-f79a-36daccab5062@palves.net> Date: Thu, 17 Jun 2021 15:38:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2021-06-15 6:04 p.m., John Baldwin wrote: > On 6/15/21 4:14 AM, Pedro Alves wrote: >> For the Ctrl-C rework series I posted recently, I stared at code using >> scoped_ignore_sigttou a lot, and it annoyed me that it isn't thread >> safe, because it changes the signal's disposition. >> >> Very recently, we got a new scoped_ignore_sigpipe class modelled on >> scoped_ignore_sigttou, which made me want to fix this before it ever >> becomes a (hard to debug) problem.  I mentioned this here: >> >>   https://sourceware.org/pipermail/gdb-patches/2021-June/179958.html > > I think this looks ok to me.  The one difference I can think of when > using sigpromask() instead of SIG_IGN is if the signal might be > sent to another thread instead of masked.  However, both SIGPIPE > and SIGTTOU sent in the context of write() should be sent to the > specific thread calling write().  SIGTTOU is a bit funky in that > it gets raised to the entire process group, but in FreeBSD at least > we only raise it if it is not masked for the current thread that > has invoked write().  (If the signal is masked, it isn't raised at > all.) Yeah, I was a bit worried about that too, but what I observe on Linux is the same as what you're describing for FreeBSD. - SIGTTOU isn't sent at all if the thread touching the terminal has it masked. - SIGPIPE is sent to the thread that writes and remains pending (hence the need for sigtimedwait). (confirmed that it was sent to the thread and now the process by inspecting the Sig* entries in /proc/TID/status.) To double check that the kernel wouldn't send the SIGTTOU signal if some other thread had it unblocked, I hacked GDB to make sure all GDB threads start with signals unblocked: --- c/gdbsupport/thread-pool.cc +++ w/gdbsupport/thread-pool.cc @@ -100,7 +100,7 @@ thread_pool::set_thread_count (size_t num_threads) { /* Ensure that signals used by gdb are blocked in the new threads. */ - block_signals blocker; + // block_signals blocker; (and then confirmed by inspecting the Sig* entries in /proc/TID/status.) If SIGTTOU ends up raised by some other thread while the main thread has it blocked in scoped_ignore_sigttou, and if it is sent to the whole process, there's a small time window where the sigtimedwait in the main thread can eat the signal. That still seems better than the current status where the end result can be that we can end up with the signal enabled instead of ignored and then gdb backgrounds itself. This is of course highly theoretical since I expect that gdb threads run with signals blocked from the get go. But you never know what Python code does.