From: Tom Tromey <tom@tromey.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH 3/3] Use unique_ptr to destroy per-bfd object
Date: Tue, 2 Aug 2022 14:14:59 -0600 [thread overview]
Message-ID: <20220802201459.2839634-4-tom@tromey.com> (raw)
In-Reply-To: <20220802201459.2839634-1-tom@tromey.com>
In some cases, the objfile owns the per-bfd object. This is yet
another object that can sometimes be destroyed before the registry is
destroyed, possibly reslting in a use-after-free. Also, I noticed
that the condition for deleting the object is not the same as the
condition used to create it -- so it could possibly result in a memory
leak in some situations. This patch fixes the problem by introducing
a new unique_ptr that holds this object when necessary.
---
gdb/objfiles.c | 22 +++++++---------------
gdb/objfiles.h | 9 +++++++--
2 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/gdb/objfiles.c b/gdb/objfiles.c
index c92da7548b3..31c27e9c3cb 100644
--- a/gdb/objfiles.c
+++ b/gdb/objfiles.c
@@ -117,9 +117,10 @@ objfile_per_bfd_storage::~objfile_per_bfd_storage ()
NULL, and it already has a per-BFD storage object, use that.
Otherwise, allocate a new per-BFD storage object. */
-static struct objfile_per_bfd_storage *
-get_objfile_bfd_data (bfd *abfd)
+void
+set_objfile_per_bfd (struct objfile *objfile)
{
+ bfd *abfd = objfile->obfd.get ();
struct objfile_per_bfd_storage *storage = NULL;
if (abfd != NULL)
@@ -133,21 +134,15 @@ get_objfile_bfd_data (bfd *abfd)
enough that this seems reasonable. */
if (abfd != NULL && !gdb_bfd_requires_relocations (abfd))
objfiles_bfd_data.set (abfd, storage);
+ else
+ objfile->per_bfd_storage.reset (storage);
/* Look up the gdbarch associated with the BFD. */
if (abfd != NULL)
storage->gdbarch = gdbarch_from_bfd (abfd);
}
- return storage;
-}
-
-/* See objfiles.h. */
-
-void
-set_objfile_per_bfd (struct objfile *objfile)
-{
- objfile->per_bfd = get_objfile_bfd_data (objfile->obfd.get ());
+ objfile->per_bfd = storage;
}
/* Set the objfile's per-BFD notion of the "main" name and
@@ -353,7 +348,7 @@ objfile::objfile (gdb_bfd_ref_ptr bfd_, const char *name, objfile_flags flags_)
build_objfile_section_table (this);
}
- per_bfd = get_objfile_bfd_data (obfd.get ());
+ set_objfile_per_bfd (this);
}
/* If there is a valid and known entry point, function fills *ENTRY_P with it
@@ -555,9 +550,6 @@ objfile::~objfile ()
if (sf != NULL)
(*sf->sym_finish) (this);
- if (obfd == nullptr)
- delete per_bfd;
-
/* Before the symbol table code was redone to make it easier to
selectively load and remove information particular to a specific
linkage unit, gdb used to do these things whenever the monolithic
diff --git a/gdb/objfiles.h b/gdb/objfiles.h
index ac45fa3980f..16dab0d2c69 100644
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -653,11 +653,16 @@ struct objfile
gdb_bfd_ref_ptr obfd;
- /* The per-BFD data. Note that this is treated specially if OBFD
- is NULL. */
+ /* The per-BFD data. */
struct objfile_per_bfd_storage *per_bfd = nullptr;
+ /* In some cases, the per_bfd object is owned by this objfile and
+ not by the BFD itself. In this situation, this holds the owning
+ pointer. */
+
+ std::unique_ptr<objfile_per_bfd_storage> per_bfd_storage;
+
/* The modification timestamp of the object file, as of the last time
we read its symbols. */
--
2.34.1
next prev parent reply other threads:[~2022-08-02 20:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 20:14 [PATCH 0/3] Fix regressions caused by registry series Tom Tromey
2022-08-02 20:14 ` [PATCH 1/3] Use gdb_bfd_ref_ptr in objfile Tom Tromey
2022-08-02 20:14 ` [PATCH 2/3] Use auto_obstack " Tom Tromey
2022-08-02 20:14 ` Tom Tromey [this message]
2022-08-03 18:02 ` [PATCH 0/3] Fix regressions caused by registry series Simon Marchi via Gdb-patches
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=20220802201459.2839634-4-tom@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.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