From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] MI: Free values when updating
Date: Tue, 23 Jan 2007 11:02:00 -0000 [thread overview]
Message-ID: <17845.60212.898642.763807@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200701231215.08114.ghost@cs.msu.su>
> > OK, it's not the right patch but I do think that release_values shouldn't
> > be called when updating;
>
> Why? If we're about to store a value in varobj->value, we must call
> release_value on that value, otherwise the value is going to be deleted at a
> random point in time, and our varobj will be rather useless.
Because there wasn't a call there before your changes.
> > it's just that this patch stops calling it at other times
> > when it's needed. Without any change, do enable timings (if you have that
> > patch), create a variable object of a large array and all its children then
> > repeatedly do "-var-update *". It should take longer and longer to execute.
>
> Why? Is it because the memory consumption of gdb grows, or because the list
> of released values grows without ever being cleared, or for some other
> reason?
The latter, I think.
>...
> As I've said, we need to do it to avoid the value to be deleted at random
> point in time. So there must be something else? Does you free_values patch
> makes any difference here?
I think the permanence of values are already guaranteed through value_of_root
and value_of_child. Maybe trying to release them the second time takes
longer because GDB has to go all the way through the list to find out they're
not there.
> - Volodya
> Index: varobj.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/varobj.c,v
> retrieving revision 1.79
> diff -u -p -r1.79 varobj.c
> --- varobj.c 16 Jan 2007 02:12:49 -0000 1.79
> +++ varobj.c 23 Jan 2007 09:12:07 -0000
> @@ -1987,11 +1987,7 @@ c_value_of_root (struct varobj **var_han
> /* We need to catch errors here, because if evaluate
> expression fails we just want to make val->error = 1 and
> go on */
This comment is not applicable anymore.
> - if (gdb_evaluate_expression (var->root->exp, &new_val))
> - {
> - release_value (new_val);
> - }
> -
> + gdb_evaluate_expression (var->root->exp, &new_val);
> return new_val;
> }
I think if you also remove the (3) calls to release_value in c_value_of_child
and cplus_value_of_child this is equivalent to my change (and more tidy).
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2007-01-23 11:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-23 7:45 Nick Roberts
2007-01-23 7:55 ` Vladimir Prus
2007-01-23 8:56 ` Nick Roberts
2007-01-23 9:15 ` Vladimir Prus
2007-01-23 11:02 ` Nick Roberts [this message]
2007-01-23 12:12 ` Daniel Jacobowitz
2007-01-23 21:19 ` Nick Roberts
2007-01-23 21:35 ` Vladimir Prus
2007-01-24 8:00 ` Vladimir Prus
2007-01-24 9:14 ` Nick Roberts
2007-01-24 9:21 ` Vladimir Prus
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=17845.60212.898642.763807@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=gdb-patches@sources.redhat.com \
--cc=ghost@cs.msu.su \
/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