Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Patrick Palka <patrick@parcs.ath.cx>
To: gdb-patches@sourceware.org
Cc: Patrick Palka <patrick@parcs.ath.cx>
Subject: [PATCH 1/2] Use gdbarch obstack to allocate types in alloc_type_arch
Date: Tue, 30 Jun 2015 02:28:00 -0000	[thread overview]
Message-ID: <1435631281-31970-1-git-send-email-patrick@parcs.ath.cx> (raw)

For the command "gdb gdb" valgrind currently reports 100s of individual
memory leaks, 500 of which originate solely out of the function
alloc_type_arch.  This function allocates a "struct type" associated
with the given gdbarch using malloc but apparently the types allocated
by this function are never freed.

This patch fixes these leaks by making the function alloc_type_arch
allocate these gdbarch-associated types on the gdbarch obstack instead
of on the general heap.  Since, from what I can tell, the types
allocated by this function are all fundamental "wired-in" types, such
types would not benefit from more granular memory management anyway.
They would likely live as long as the gdbarch is alive so allocating
them on the gdbarch obstack makes sense.

With this patch, the number of individual vargrind warnings emitted for
the command "gdb gdb" drops from ~800 to ~300.

Tested on x86_64-unknown-linux-gnu.  Does this fix make sense?  It may
not be ideal (more disciplined memory management may be?), but for the
time being it helps reduce the noise coming from valgrind.  Or maybe
there is a good reason that these types are allocated on the heap...

gdb/ChangeLog:

	* gdbtypes.c (alloc_type_arch): Allocate the type on the given
	gdbarch obstack instead of on the heap.  Update commentary
	accordingly.
---
 gdb/gdbtypes.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index ca86fbd..979ed6c 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -187,7 +187,7 @@ alloc_type (struct objfile *objfile)
 
 /* Allocate a new GDBARCH-associated type structure and fill it
    with some defaults.  Space for the type structure is allocated
-   on the heap.  */
+   on the obstack associated with GDBARCH.  */
 
 struct type *
 alloc_type_arch (struct gdbarch *gdbarch)
@@ -198,8 +198,8 @@ alloc_type_arch (struct gdbarch *gdbarch)
 
   /* Alloc the structure and start off with all fields zeroed.  */
 
-  type = XCNEW (struct type);
-  TYPE_MAIN_TYPE (type) = XCNEW (struct main_type);
+  type = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct type);
+  TYPE_MAIN_TYPE (type) = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct main_type);
 
   TYPE_OBJFILE_OWNED (type) = 0;
   TYPE_OWNER (type).gdbarch = gdbarch;
-- 
2.5.0.rc0.5.g91e10c5.dirty


             reply	other threads:[~2015-06-30  2:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30  2:28 Patrick Palka [this message]
2015-06-30  2:28 ` [PATCH 2/2] Use gdbarch obstack to allocate the TYPE_NAME string in arch_type Patrick Palka
2015-06-30  9:36   ` Pedro Alves
2015-06-30 20:05     ` Patrick Palka
2015-08-29 12:59       ` Patrick Palka
2015-08-29 18:20   ` Doug Evans
2015-08-29 21:29     ` Patrick Palka
2015-08-29 22:33       ` Patrick Palka
2015-09-02  5:12         ` Doug Evans
2015-08-29 18:06 ` [PATCH 1/2] Use gdbarch obstack to allocate types in alloc_type_arch Doug Evans
2015-08-29 21:26   ` Patrick Palka
2015-08-29 21:35     ` Doug Evans
2015-08-29 22:30       ` Patrick Palka
2015-08-29 22:31         ` Patrick Palka

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=1435631281-31970-1-git-send-email-patrick@parcs.ath.cx \
    --to=patrick@parcs.ath.cx \
    --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