Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [RFA/commit] Memory leak in on reading frame register
Date: Fri, 08 May 2015 15:55:00 -0000	[thread overview]
Message-ID: <1431100524-7793-1-git-send-email-brobecker@adacore.com> (raw)

[On behalf of Jerome  Guitton]

When using a conditional breakpoint where the condition evaluated
to false a large number of times before the program stopped,
a user reported that GDB's memory consumption was growing very
quickly until it ran out of memory.

The problem was tracked down to temporary struct values being created
each time the program stops and we evaluate those conditions. This
patch fixes the issue by releasing the temporary values, and adds
a comment explaining why we do that.

gdb/ChangeLog:

        Jerome Guitton  <guitton@adacore.com>:
	* findvar.c (read_frame_register_value): Fix a memory leak.

Tested on x86_64-linux. No regression.

I'll push the patch in a week or so, pending comments.

Thanks,
-- 
Joel

---
 gdb/findvar.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/gdb/findvar.c b/gdb/findvar.c
index 2079b4b..8ccf267 100644
--- a/gdb/findvar.c
+++ b/gdb/findvar.c
@@ -686,6 +686,17 @@ read_frame_register_value (struct value *value, struct frame_info *frame)
 
       value_contents_copy (value, offset, regval, reg_offset, reg_len);
 
+      /* Release regval right away, as we know we do not need it anymore.
+	 Otherwise, those values just keep accumulating until they finally
+	 get released when the current command finishes (as part of the
+	 all_values chain cleanup).  While this works most of the time,
+	 we have observed that, when using a conditional breakpoint where
+	 the condition gets repeatedly evaluated to false, keeping those
+	 values in memory causes a rapid and measurable growth in memory
+	 consumption, eventually leading us to running out of memory.  */
+      release_value (regval);
+      value_free (regval);
+
       offset += reg_len;
       len -= reg_len;
       reg_offset = 0;
-- 
1.9.1


             reply	other threads:[~2015-05-08 15:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08 15:55 Joel Brobecker [this message]
2015-05-11 10:55 ` Pedro Alves
2015-05-11 20:53   ` Joel Brobecker
2015-05-12  9:43     ` Pedro Alves
2015-05-15 15:58       ` Joel Brobecker
2015-05-15 22:35         ` Doug Evans
2015-05-16  0:03           ` Joel Brobecker
2015-05-19 10:04         ` Pedro Alves
2015-05-20  7:39           ` pushed: " Joel Brobecker

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=1431100524-7793-1-git-send-email-brobecker@adacore.com \
    --to=brobecker@adacore.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