From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5009 invoked by alias); 25 Mar 2010 19:20:37 -0000 Received: (qmail 4994 invoked by uid 22791); 25 Mar 2010 19:20:35 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Mar 2010 19:20:22 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NusbL-0003mE-Vs for gdb-patches@sources.redhat.com; Thu, 25 Mar 2010 20:20:19 +0100 Received: from enigma.qnx.com ([209.226.137.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Mar 2010 20:20:19 +0100 Received: from aristovski by enigma.qnx.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Mar 2010 20:20:19 +0100 To: gdb-patches@sources.redhat.com From: Aleksandar Ristovski Subject: Re: [patch] varobj.c c_describe_child Date: Thu, 25 Mar 2010 19:20:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 In-Reply-To: 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: 2010-03/txt/msg00855.txt.bz2 On 25/03/2010 2:29, Tom Tromey wrote: >>>>>> "Aleksandar" == Aleksandar Ristovski writes: > > Aleksandar> Note that with latest gdb from HEAD it doesn't crash, I > Aleksandar> believe due to recent changes in lazy allocating the values, > Aleksandar> but it still seems wrong to keep all these intermediate > Aleksandar> values generated by adjust_value_for_child_access' in > Aleksandar> 'all_values' list. > > I think these values will automatically be freed the next time an MI > command is executed. The call chain is mi_cmd_execute -> > prepare_execute_command -> free_all_values. Yes. However, in gdb 6.8, it will not get a chance since it crashes before finishing creating children (on HEAD gdb it doesn't crash, I believe due to lazy mechanism). > > Or is the idea to limit the transient amount of memory used? > I can't tell from the patch. Yes, the idea is to reduce amount of transient memory. > > In that case, I think it would be more typical to use > value_mark and value_free_to_mark. What is happening (in a loop for each field of the struct) is: - create value for the parent type (huge struct) - create value for the field and then repeat all that. I believe value_mark would not work since value that we do want to keep is interspersed with the ones we can discard. Maybe the right fix is to create a varobj of pointed-to type as a child to pointer-to varobj, and then calculate children for this new varobj? Or introduce "target_value" in varobj struct? Not sure. The patch I proposed reduces the issue but is not solving it completely. Thanks, -- Aleksandar Ristovski QNX Software Systems