public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Tom Tromey <tromey@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] Use unique_ptr to destroy per-bfd object
Date: Wed,  3 Aug 2022 19:42:25 +0000 (GMT)	[thread overview]
Message-ID: <20220803194225.91BDA385828D@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=88c4cce8d28e6be486cb25fbbccf2b42e40da45b

commit 88c4cce8d28e6be486cb25fbbccf2b42e40da45b
Author: Tom Tromey <tom@tromey.com>
Date:   Tue Aug 2 12:01:01 2022 -0600

    Use unique_ptr to destroy per-bfd object
    
    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.

Diff:
---
 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 @@ public:
 
   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.  */


                 reply	other threads:[~2022-08-03 19:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220803194225.91BDA385828D@sourceware.org \
    --to=tromey@sourceware.org \
    --cc=gdb-cvs@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).