From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3673 invoked by alias); 19 Mar 2012 06:17:26 -0000 Received: (qmail 3658 invoked by uid 22791); 19 Mar 2012 06:17:23 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_QE 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; Mon, 19 Mar 2012 06:17:00 +0000 Received: from m2.gw.fujitsu.co.jp (unknown [10.0.50.72]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 9C5F93EE0B5 for ; Mon, 19 Mar 2012 15:16:58 +0900 (JST) Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 852A845DE4D for ; Mon, 19 Mar 2012 15:16:58 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 613C045DD74 for ; Mon, 19 Mar 2012 15:16:58 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 52D451DB803F for ; Mon, 19 Mar 2012 15:16:58 +0900 (JST) Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.240.81.133]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id EBA0FE08001 for ; Mon, 19 Mar 2012 15:16:57 +0900 (JST) Received: from ml13.css.fujitsu.com (ml13 [127.0.0.1]) by ml13.s.css.fujitsu.com (Postfix) with ESMTP id B5032FD0028 for ; Mon, 19 Mar 2012 15:16:57 +0900 (JST) Received: from localhost (unknown [10.124.102.140]) by ml13.s.css.fujitsu.com (Postfix) with ESMTP id 20CE0FD0030 for ; Mon, 19 Mar 2012 15:16:57 +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]); Mon, 19 Mar 2012 15:16:52 +0900 (JST) Date: Mon, 19 Mar 2012 06:17:00 -0000 Message-Id: <20120319.151647.104032080.d.hatayama@jp.fujitsu.com> To: gdb-patches@sourceware.org Subject: question: python gc doesn't collect buffer allocated by read_memory() From: HATAYAMA Daisuke 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/msg00690.txt.bz2 Hello, I want to use read_memory() to read memory of core file of qemu-kvm process that contains KVM guest memory. The problem is that garbage collector never tries to collect the memory allocated during read_memory() processing. So, for large qemu-kvm core file, doing this leads to OOM. I show an example, which is essentially the same as the issue I faced. 1. First, create a core file for test. The core file has buffer of 4096 bytes, which is intended to be read many times afterward. # cat testpro.c char buf[4096]; int main(int argc, char **argv) { *(char *)0 = 1; return 0; } # gcc -g ./testpro.c -o testpro # ulimit -c unlimited # ./testpro Segmentation fault (core dumped) # ls core.* core.4301 2. Second, open it with gdb. # gdb ./testpro ./core.4301 3. Use a python script that reads buf a lot of times, and so allocates a lot of memory during the processing. (gdb) shell cat testpro.py 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 (gdb) shell ps aux | head -n 1 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND (gdb) shell ps aux | grep gdb | grep -v grep root 4728 0.1 0.7 132560 14752 pts/3 S+ Mar19 0:00 gdb ./testpro ./core.4301 (gdb) source ./testpro.py (gdb) shell ps aux | grep gdb | grep -v grep root 4728 24.8 22.1 542500 424900 pts/3 S+ Mar19 0:37 gdb ./testpro ./core.4301 So, we see that used memory increased from 132560 KB to 542500 KB. 4. Try to trigger garbage collector, but it appears to be meaningless. (gdb) python gc.collect() (gdb) shell ps aux | grep gdb | grep -v grep root 4728 23.1 22.1 542500 424904 pts/3 S+ Mar19 0:37 gdb ./testpro ./core.4301 (gdb) shell ps aux | grep gdb | grep -v grep root 4728 22.3 22.1 542500 424904 pts/3 S+ Mar19 0:37 gdb ./testpro ./core.4301 (gdb) shell ps aux | grep gdb | grep -v grep root 4728 22.3 22.1 542500 424904 pts/3 S+ Mar19 0:37 gdb ./testpro ./core.4301 (gdb) shell ps aux | grep gdb | grep -v grep root 4728 22.2 22.1 542500 424904 pts/3 S+ Mar19 0:37 gdb ./testpro ./core.4301 (gdb) shell ps aux | grep gdb | grep -v grep root 4728 22.0 22.1 542500 424904 pts/3 S+ Mar19 0:37 gdb ./testpro ./core.4301 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... (gdb) shell cat testpro2.py import gdb import gc i = gdb.inferiors()[0] buf = gdb.parse_and_eval('buf') print gc.get_referrers(i.read_memory(buf.address, buf.type.sizeof)) (gdb) source testpro2.py [] So, could anyone point at me if I'm wrong anyware? If there's no alternative, I want another variant of read_memory() that receives buffer in the 3rd argument; just like: read_memory(address, length, buffer) Thanks. HATAYAMA, Daisuke