From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23336 invoked by alias); 27 Mar 2012 01:52:32 -0000 Received: (qmail 23325 invoked by uid 22791); 27 Mar 2012 01:52:31 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from fgwmail6.fujitsu.co.jp (HELO fgwmail6.fujitsu.co.jp) (192.51.44.36) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Mar 2012 01:52:17 +0000 Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 30F853EE0B5 for ; Tue, 27 Mar 2012 10:52:15 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 1447845DE5A for ; Tue, 27 Mar 2012 10:52:15 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id E79AF45DE55 for ; Tue, 27 Mar 2012 10:52:14 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id D6D29E08001 for ; Tue, 27 Mar 2012 10:52:14 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.240.81.145]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 8473AE08002 for ; Tue, 27 Mar 2012 10:52:14 +0900 (JST) Received: from m105.css.fujitsu.com (m105 [127.0.0.1]) by m105.s.css.fujitsu.com (Postfix) with ESMTP id 52AE95D8004; Tue, 27 Mar 2012 10:52:14 +0900 (JST) Received: from localhost (unknown [10.124.102.140]) by m105.s.css.fujitsu.com (Postfix) with ESMTP id E9B0C5D8001; Tue, 27 Mar 2012 10:52:13 +0900 (JST) X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Received: from univ9680[10.124.102.140] by univ9680 (FujitsuOutboundMailChecker v1.3.1/9992[10.124.102.140]); Tue, 27 Mar 2012 10:52:11 +0900 (JST) Date: Tue, 27 Mar 2012 01:52:00 -0000 Message-Id: <20120327.105206.71087856.d.hatayama@jp.fujitsu.com> To: tromey@redhat.com Cc: gdb-patches@sourceware.org Subject: Re: question: python gc doesn't collect buffer allocated by read_memory() From: HATAYAMA Daisuke In-Reply-To: <87iphrs3ip.fsf@fleche.redhat.com> References: <87iphzhtvd.fsf@fleche.redhat.com> <20120321.131547.347143263.d.hatayama@jp.fujitsu.com> <87iphrs3ip.fsf@fleche.redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2012-03/txt/msg00900.txt.bz2 Hello Tom, From: Tom Tromey Subject: Re: question: python gc doesn't collect buffer allocated by read_memory() Date: Mon, 26 Mar 2012 10:58:22 -0600 >>>>>> ">" == HATAYAMA Daisuke writes: > >>> Sorry for missing. I first found this on gdb-7.2-48.el6.x86_64. I used >>> 7.4 in the presentation of the first mail. > > Thanks. > >>> On the other hand, it appears to me that buffer objects returned by >>> inferior.read_memory() is never collected by gc.collect(). > > I think I found the problem. > > The issue is that PyBuffer_FromReadWriteObject acquires a reference to > the base object -- but the code in gdb assumed that it stole a reference. > > Could you try the appended patch? > It works for me; if it works for you, I will put it in. > If you can't try it, I'll just assume it is ok and go ahead... > > Tom > Thanks! I was also looking into py-inferior.c but I've first started with studying python gc and it must have been taken more time. I tried your patch using gdb of today's daily update and the same script below. import gdb import gc i = gdb.inferiors()[0] buf = gdb.parse_and_eval('buf') count = 100000 while count >= 0: i.read_memory(buf.address, buf.type.sizeof) count -= 1 gc.collect() I typed ps aux command to see VSZ/RSS each time I executed the script above that reads 4KB buffer 100000 times so about 390MB total. [Before] $ ps aux | head -1 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND $ ps aux | grep gdb | grep -v grep hat 28438 1.0 0.3 81936 12340 pts/1 S+ 10:15 0:00 /media/pub/repos/gdb/gdb/gdb ./testpro ./core.27403 $ ps aux | grep gdb | grep -v grep hat 28438 9.3 10.7 491876 422296 pts/1 S+ 10:15 0:01 /media/pub/repos/gdb/gdb/gdb ./testpro ./core.27403 400 MB increased. [After] $ ps aux | head -1 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND $ ps aux | grep gdb | grep -v grep hat 28446 8.6 0.4 86164 16756 pts/1 S+ 10:15 0:00 /media/pub/repos/gdb/gdb.fixed ./testpro ./core.27403 $ ps aux | grep gdb | grep -v grep hat 28446 1.5 0.5 90928 21444 pts/1 S+ 10:15 0:01 /media/pub/repos/gdb/gdb.fixed ./testpro ./core.27403 4 MB increased. So, it seems to me that buffers allocated in infpy_read_memory() are now collected sanely. I confirm the issue I reported has been fixed. BTW, there is still about 4MB increment. I tried two more times, then still saw constant increase. $ ps aux | grep gdb | grep -v grep hat 28446 2.1 0.6 95548 26132 pts/1 S+ 10:15 0:02 /media/pub/repos/gdb/gdb.fixed ./testpro ./core.27403 $ ps aux | grep gdb | grep -v grep hat 28446 0.7 0.7 100304 30820 pts/1 S+ 10:15 0:02 /media/pub/repos/gdb/gdb.fixed ./testpro ./core.27403 And the increment can be reproduced by simplifying the script to i.read_memory() only. (gdb) python >count=100000 >while count >= 0: > i.read_memory(addr, size) > count -= 1 >gc.collect() >end I suspect another objects allocated remain while not collected. Thanks. HATAYAMA, Daisuke