From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org, Jerome Guitton <guitton@adacore.com>
Subject: Re: [RFA/commit] Memory leak in on reading frame register
Date: Mon, 11 May 2015 20:53:00 -0000 [thread overview]
Message-ID: <20150511205312.GE4767@adacore.com> (raw)
In-Reply-To: <55508A83.3060605@redhat.com>
> > 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.
> >
>
> Not sure about this.
>
> How come this in bpstat_check_breakpoint_conditions didn't
> handle this issue already? :
>
> ...
> /* We use value_mark and value_free_to_mark because it could
> be a long time before we return to the command level and
> call free_all_values. We can't call free_all_values
> because we might be in the middle of evaluating a
> function call. */
> struct value *mark = value_mark ();
>
> ...
> value_free_to_mark (mark);
An excellent question, which I will try to research in the next
couple of days!
...
> Otherwise, what is releasing other kinds of temporary values?
> Are we leaking them? E.g., with:
>
> int global_val;
> void foo () {}
> int main () { while (1) foo (); }
>
> and then:
>
> (gdb) break foo if global_var == 1
>
> an/or:
>
> (gdb) break foo if (global_var + 1) == 2
>
>
> Maybe nothing breaks with this patch as its deleting register lval
> values, but the case above would involve lval_memory values,
> and if we did something for those like in this patch, I fear
> that places that want to walk an expression's value chain,
> like update_watchpoint / can_use_hardware_watchpoint would break.
But I confess I don't quite understand what you mean by the above.
Are you saying that the current patch may be OK (because we're
creating and deleting a value that we know is independent of all
other values), but that it sets a precendent for other forms where
it might not be OK?
--
Joel
next prev parent reply other threads:[~2015-05-11 20:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 15:55 Joel Brobecker
2015-05-11 10:55 ` Pedro Alves
2015-05-11 20:53 ` Joel Brobecker [this message]
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=20150511205312.GE4767@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=guitton@adacore.com \
--cc=palves@redhat.com \
/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).