From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@polymtl.ca>
Subject: [PATCH v2] [gdb] Fix assert in delete_breakpoint
Date: Tue, 28 Nov 2023 16:01:21 +0100 [thread overview]
Message-ID: <20231128150121.23760-1-tdevries@suse.de> (raw)
On a pinebook (aarch64 with 64-bit kernel and 32-bit userland) with test-case
gdb.base/gdb-sigterm.exp I run into:
...
intrusive_list.h:458: internal-error: erase_element: \
Assertion `elem_node->prev != INTRUSIVE_LIST_UNLINKED_VALUE' failed.^M
...
which happens while executing this statement in delete_breakpoint:
...
breakpoint_chain.erase (breakpoint_chain.iterator_to (*bpt));
...
The following events lead to the assertion failure:
- a single-step breakpoint is hit,
- delete_just_stopped_threads_single_step_breakpoints is called,
- during delete_just_stopped_threads_single_step_breakpoints,
delete_breakpoint is called,
- breakpoint_chain.erase is called,
- gdb is interrupted by SIGTERM before finishing delete_breakpoint.
The interrupt happens due to a QUIT during a target_write_with_progress
call, which is called during default_memory_remove_breakpoint,
- the SIGTERM triggers a SCOPE_EXIT cleanup, calling
delete_just_stopped_threads_infrun_breakpoints which ends up
calling delete_breakpoint again for the same breakpoint, and
- breakpoint_chain.erase is called the second time, and the assert triggers.
There is an ad-hoc reentrancy control mechanism in delete_breakpoint:
...
void
delete_breakpoint (struct breakpoint *bpt)
{
....
if (bpt->type == bp_none)
return;
...
bpt->type = bp_none;
...
}
...
which partitions up the function into three parts:
- an initial part that is always executed,
- a second part that can be executed more than once per breakpoint, and
- a third part that can be executed only once per breakpoint.
One way of looking at the assertion failure is that commit e2a1578868a ("gdb:
link breakpoints with intrusive_list") introduced code in the second part that
cannot be executed more than once, which can be fixed by guarding the
breakpoint_chain.erase call with is_linked.
Another way of looking at it is to ask the question: if we're so eager to
delete the breakpoint that we call it as a SCOPE_EXIT cleanup, why do we allow
it to be interrupted in the first place?
Fix this by suppressing QUIT during delete_breakpoint.
Tested on the pinebook and x86_64-linux.
PR gdb/31061
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31061
---
gdb/breakpoint.c | 3 +++
gdb/utils.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
gdb/utils.h | 21 +++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 699919e32b3..768b92676f8 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -12582,6 +12582,9 @@ notify_breakpoint_deleted (breakpoint *b)
void
delete_breakpoint (struct breakpoint *bpt)
{
+ /* Make sure that the function cannot be interrupted by QUIT. */
+ scoped_suppress_quit do_scoped_suppress_quit;
+
gdb_assert (bpt != NULL);
/* Has this bp already been deleted? This can happen because
diff --git a/gdb/utils.c b/gdb/utils.c
index 7a1841ba21e..405f5de29c4 100644
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -654,6 +654,48 @@ quit (void)
#endif
}
+/* See utils.h. */
+
+int scoped_suppress_quit::suppress_quit_enabled_cnt;
+bool scoped_suppress_quit::suppress_quit_seen;
+
+/* See utils.h. */
+
+scoped_suppress_quit::scoped_suppress_quit ()
+{
+ gdb_assert (is_main_thread ());
+ suppress_quit_enabled_cnt++;
+}
+
+/* See utils.h. */
+
+scoped_suppress_quit::~scoped_suppress_quit () noexcept(false)
+{
+ suppress_quit_enabled_cnt--;
+ gdb_assert (suppress_quit_enabled_cnt >= 0);
+
+ if (suppress_quit_enabled_cnt != 0)
+ return;
+
+ bool tmp_suppress_quit_seen = suppress_quit_seen;
+ suppress_quit_seen = false;
+
+ if (!tmp_suppress_quit_seen)
+ return;
+
+ /* A QUIT was suppressed, unsuppress it here. This may throw. */
+ QUIT;
+}
+
+/* See utils.h. */
+
+bool
+scoped_suppress_quit::suppress_quit_enabled ()
+{
+ suppress_quit_seen = true;
+ return suppress_quit_enabled_cnt > 0;
+}
+
/* See defs.h. */
void
@@ -662,6 +704,9 @@ maybe_quit (void)
if (!is_main_thread ())
return;
+ if (scoped_suppress_quit::suppress_quit_enabled ())
+ return;
+
if (sync_quit_force_run)
quit ();
diff --git a/gdb/utils.h b/gdb/utils.h
index f646b300530..03a76a035b4 100644
--- a/gdb/utils.h
+++ b/gdb/utils.h
@@ -425,4 +425,25 @@ struct deferred_warnings
std::vector<string_file> m_warnings;
};
+/* RAII-style class to suppress the effect of calling QUIT until scope exit. */
+
+class scoped_suppress_quit
+{
+public:
+
+ scoped_suppress_quit ();
+ ~scoped_suppress_quit () noexcept(false);
+
+ /* Whether suppression is currently active. */
+ static bool suppress_quit_enabled ();
+
+private:
+
+ /* Nesting level. */
+ static int suppress_quit_enabled_cnt;
+
+ /* Whether QUIT was called during suppression. */
+ static bool suppress_quit_seen;
+};
+
#endif /* UTILS_H */
base-commit: 14414227bfac8ef1803715b3b642f8ba0ab6fff8
--
2.35.3
next reply other threads:[~2023-11-28 15:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 15:01 Tom de Vries [this message]
2024-01-02 17:00 ` Thiago Jung Bauermann
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=20231128150121.23760-1-tdevries@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).