From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: gdb-patches@sourceware.org
Subject: question: python gc doesn't collect buffer allocated by read_memory()
Date: Mon, 19 Mar 2012 06:17:00 -0000 [thread overview]
Message-ID: <20120319.151647.104032080.d.hatayama@jp.fujitsu.com> (raw)
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
<cut>
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
next reply other threads:[~2012-03-19 6:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 6:17 HATAYAMA Daisuke [this message]
2012-03-20 20:59 ` Tom Tromey
2012-03-21 4:16 ` HATAYAMA Daisuke
2012-03-26 18:56 ` Tom Tromey
2012-03-27 1:52 ` HATAYAMA Daisuke
2012-03-28 17:37 ` Tom Tromey
2012-03-29 0:49 ` HATAYAMA Daisuke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120319.151647.104032080.d.hatayama@jp.fujitsu.com \
--to=d.hatayama@jp.fujitsu.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox