From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28337 invoked by alias); 20 Mar 2012 20:59:02 -0000 Received: (qmail 28329 invoked by uid 22791); 20 Mar 2012 20:59:02 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Mar 2012 20:58:49 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2KKwlvu006607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 16:58:47 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2KKwk3L031904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2012 16:58:47 -0400 From: Tom Tromey To: HATAYAMA Daisuke Cc: gdb-patches@sourceware.org Subject: Re: question: python gc doesn't collect buffer allocated by read_memory() References: <20120319.151647.104032080.d.hatayama@jp.fujitsu.com> Date: Tue, 20 Mar 2012 20:59:00 -0000 In-Reply-To: <20120319.151647.104032080.d.hatayama@jp.fujitsu.com> (HATAYAMA Daisuke's message of "Mon, 19 Mar 2012 15:16:47 +0900 ( )") Message-ID: <87iphzhtvd.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-03/txt/msg00757.txt.bz2 >>>>> ">" == HATAYAMA Daisuke writes: >> count = 100000 >> while count >= 0: >> i.read_memory(buf.address, buf.type.sizeof) >> count -= 1 You don't say what version of gdb you are using. What you are reporting sounds like PR 12533, which was fixed in CVS back in January. >> 5. Looking at referrers of the buffer returned by read_memory(), they >> are all empty [], so it looks OK to me if garbage collector collects >> the memory... In 12533 the problem was that intermediate values weren't properly deallocated. You could test for this problem by hoisting 'buf.address' out of the loop and seeing if that has an effect. Tom