From: Pedro Alves <pedro@palves.net>
To: John Baldwin <jhb@FreeBSD.org>, gdb-patches@sourceware.org
Subject: [pushed] Don't call sigtimedwait for scoped_ignore_sigttou
Date: Thu, 17 Jun 2021 19:44:24 +0100 [thread overview]
Message-ID: <7f6edc2b-b684-05bc-aa47-400f8c12616f@palves.net> (raw)
In-Reply-To: <beb64cfb-0a34-eb71-21dc-92b5afa52ba3@FreeBSD.org>
On 2021-06-17 5:45 p.m., John Baldwin wrote:
> On 6/17/21 8:36 AM, Pedro Alves wrote:
>> On 2021-06-17 3:38 p.m., Pedro Alves wrote:
>>> On 2021-06-15 6:04 p.m., John Baldwin wrote:
>>
>>> 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.
>>>
>>
>> Hmm, I just thought of an easy fix for that. Just don't consume the pending
>> signal in SIGTTOU's case. I wonder how portable is this? WDYT?
>>
>> I'll see if I can try this on Solaris.
>
> I think this is ok. I suspect that some of the rules around SIGTTOU are in POSIX as I
> think job control is in POSIX, so (hopefully) the behavior there is fairly uniform.
> I strongly suspect the other BSD's all follow FreeBSD at least, so if Solaris is the
> same I'd feel pretty good about this behavior being consistent.
>
I tested this on the Solaris 11.3 SPARC machine on the compile farm (gcc211). I did
not get any spurious SIGTTOU so it must mean the signal wasn't sent at all there either.
I tried to test on AIX (gcc119 on the compile farm), but the build is broken there due
to PR 27123, and even with an evil hack to get past that, for some reason I couldn't
get GDB to build against the GMP on the system. So I gave up...
I did notice that the "maint selftest scoped_ignore_sigpipe" test fails on Solaris,
bitten by BSD signal semantics, which I forgot to handle... I'll fix that in a bit.
Here's the patch that I merged. Thanks for the help John.
From 336b30e58ae98fe66862ab8480d3f7bb885fef23 Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Thu, 17 Jun 2021 16:23:03 +0100
Subject: [PATCH] Don't call sigtimedwait for scoped_ignore_sigttou
Because SIGTTOU is sent to the whole process instead of to a specific
thread, consuming a pending SIGTTOU in the destructor of
scoped_ignore_sigttou could consume a SIGTTOU signal raised due to
actions done by some other thread. Simply avoid sigtimedwait in
scoped_ignore_sigttou, thus plugging the race. This works because we
know that when the thread writes to the terminal and the signal is
blocked, the kernel does not raise the signal at all.
Tested on GNU/Linux, Solaris 11 and FreeBSD.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* scoped_ignore_signal.h (scoped_ignore_signal): Add
ConsumePending template parameter.
(scoped_ignore_signal::~scoped_ignore_signal): Skip calling
sigtimedwait if ConsumePending is false.
(scoped_ignore_sigpipe): Initialize with ConsumePending=true.
* scoped_ignore_sigttou.h (scoped_ignore_sigttou)
<m_ignore_signal>: Initialize with ConsumePending=false.
Change-Id: I92f754dbc45c45819dce2ce68b8c067d8d5c61b1
---
gdb/ChangeLog | 10 ++++++++++
gdbsupport/scoped_ignore_signal.h | 18 +++++++++++++-----
gdbsupport/scoped_ignore_sigttou.h | 2 +-
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index e4e58173ee6..c70f6ef5329 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,13 @@
+2021-06-17 Pedro Alves <pedro@palves.net>
+
+ * scoped_ignore_signal.h (scoped_ignore_signal): Add
+ ConsumePending template parameter.
+ (scoped_ignore_signal::~scoped_ignore_signal): Skip calling
+ sigtimedwait if ConsumePending is false.
+ (scoped_ignore_sigpipe): Initialize with ConsumePending=true.
+ * scoped_ignore_sigttou.h (scoped_ignore_sigttou)
+ <m_ignore_signal>: Initialize with ConsumePending=false.
+
2021-06-17 Pedro Alves <pedro@palves.net>
* Makefile.in (SELFTESTS_SRCS): Add
diff --git a/gdbsupport/scoped_ignore_signal.h b/gdbsupport/scoped_ignore_signal.h
index 55a921cb332..a14c96779bf 100644
--- a/gdbsupport/scoped_ignore_signal.h
+++ b/gdbsupport/scoped_ignore_signal.h
@@ -25,9 +25,16 @@
/* RAII class used to ignore a signal in a scope. If sigprocmask is
supported, then the signal is only ignored by the calling thread.
Otherwise, the signal disposition is set to SIG_IGN, which affects
- the whole process. */
-
-template <int Sig>
+ the whole process. If ConsumePending is true, the destructor
+ consumes a pending Sig. SIGPIPE for example is queued on the
+ thread even if blocked at the time the pipe is written to. SIGTTOU
+ OTOH is not raised at all if the thread writing to the terminal has
+ it blocked. Because SIGTTOU is sent to the whole process instead
+ of to a specific thread, consuming a pending SIGTTOU in the
+ destructor could consume a signal raised due to actions done by
+ some other thread. */
+
+template <int Sig, bool ConsumePending>
class scoped_ignore_signal
{
public:
@@ -58,7 +65,8 @@ class scoped_ignore_signal
/* If we got a pending Sig signal, consume it before
unblocking. */
- sigtimedwait (&set, nullptr, &zero_timeout);
+ if (ConsumePending)
+ sigtimedwait (&set, nullptr, &zero_timeout);
sigprocmask (SIG_UNBLOCK, &set, nullptr);
}
@@ -89,7 +97,7 @@ struct scoped_ignore_signal_nop
};
#ifdef SIGPIPE
-using scoped_ignore_sigpipe = scoped_ignore_signal<SIGPIPE>;
+using scoped_ignore_sigpipe = scoped_ignore_signal<SIGPIPE, true>;
#else
using scoped_ignore_sigpipe = scoped_ignore_signal_nop;
#endif
diff --git a/gdbsupport/scoped_ignore_sigttou.h b/gdbsupport/scoped_ignore_sigttou.h
index 1fc8f80d7fd..5695c5db905 100644
--- a/gdbsupport/scoped_ignore_sigttou.h
+++ b/gdbsupport/scoped_ignore_sigttou.h
@@ -75,7 +75,7 @@ class scoped_ignore_sigttou
DISABLE_COPY_AND_ASSIGN (scoped_ignore_sigttou);
private:
- lazy_init<scoped_ignore_signal<SIGTTOU>> m_ignore_signal;
+ lazy_init<scoped_ignore_signal<SIGTTOU, false>> m_ignore_signal;
};
#else
base-commit: e013d20dc73b40d4b70c4a366c9adc619503e66b
--
2.26.2
next prev parent reply other threads:[~2021-06-17 18:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 11:14 [PATCH 0/4] Introduce scoped_ignore_signal & make it thread safe Pedro Alves
2021-06-15 11:14 ` [PATCH 1/4] Move scoped_ignore_sigttou to gdbsupport/ Pedro Alves
2021-06-15 11:14 ` [PATCH 2/4] Introduce scoped_restore_signal Pedro Alves
2021-06-17 14:57 ` Pedro Alves
2021-06-15 11:14 ` [PATCH 3/4] scoped_ignore_signal: Use sigprocmask+sigtimedwait instead of signal Pedro Alves
2021-06-26 12:35 ` Simon Marchi via Gdb-patches
2021-06-26 13:41 ` John Baldwin
2021-06-26 19:10 ` Simon Marchi via Gdb-patches
2021-06-27 14:55 ` Pedro Alves
2021-06-27 19:01 ` Simon Marchi via Gdb-patches
2021-06-15 11:14 ` [PATCH 4/4] Add a unit test for scoped_ignore_sigpipe Pedro Alves
2021-06-15 22:26 ` Lancelot SIX via Gdb-patches
2021-06-17 13:00 ` Pedro Alves
2021-06-15 17:04 ` [PATCH 0/4] Introduce scoped_ignore_signal & make it thread safe John Baldwin
2021-06-17 14:38 ` Pedro Alves
2021-06-17 15:36 ` Pedro Alves
2021-06-17 16:45 ` John Baldwin
2021-06-17 18:44 ` Pedro Alves [this message]
2021-06-15 20:16 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7f6edc2b-b684-05bc-aa47-400f8c12616f@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox