From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 437 invoked by alias); 23 Jan 2007 21:19:57 -0000 Received: (qmail 427 invoked by uid 22791); 23 Jan 2007 21:19:57 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Jan 2007 21:19:51 +0000 Received: from kahikatea.snap.net.nz (130.62.255.123.dynamic.snap.net.nz [123.255.62.130]) by viper.snap.net.nz (Postfix) with ESMTP id 68D863D82FB; Wed, 24 Jan 2007 10:19:43 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 3FE464F71F; Wed, 24 Jan 2007 10:19:43 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17846.31726.382269.143176@kahikatea.snap.net.nz> Date: Tue, 23 Jan 2007 21:19:00 -0000 To: Daniel Jacobowitz Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI: Free values when updating In-Reply-To: <20070123121147.GA32010@nevyn.them.org> References: <17845.48393.877158.536969@kahikatea.snap.net.nz> <17845.52624.949137.508231@kahikatea.snap.net.nz> <200701231215.08114.ghost@cs.msu.su> <17845.60212.898642.763807@kahikatea.snap.net.nz> <20070123121147.GA32010@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.92.14 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00483.txt.bz2 > > > 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. > > Except that there isn't a list of released values. So what is GDB > doing that is taking longer and longer? The list of *unreleased* values (all_values?) grows. That should change now free_all_values gets called from mi_execute_command. > > 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). > > No, those are different. They come from things like the call to > gdb_value_ind in c_describe_child. That creates a new value, which is > returned to the caller (the MI front end, to be printed and later > released). It's the ones in c_value_of_root which matter, because we > save them in the varobj. In varobj_update: new = value_of_child (v->parent, v->index); if (install_new_value (v, new, 0 /* type not changed */)) In create_child: value = value_of_child (parent, index); ... install_new_value (child, value, 1); Now install_new_value calls release_value on new, it's not neeeded in *_value_of_child. I've tried this change on the MI testsuite and see no fails and it has about the same time improvement that my patch had. If this is not the right patch then the testsuite is lacking the appropriate test. Can you create a test where this patch fails? -- Nick http://www.inet.net.nz/~nickrob