From: HATAYAMA Daisuke <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()
Date: Thu, 29 Mar 2012 00:49:00 -0000 [thread overview]
Message-ID: <20120329.094856.310071246.d.hatayama@jp.fujitsu.com> (raw)
In-Reply-To: <871uoc1va3.fsf@fleche.redhat.com>
From: Tom Tromey <tromey@redhat.com>
Subject: Re: question: python gc doesn't collect buffer allocated by read_memory()
Date: Wed, 28 Mar 2012 11:37:40 -0600
>>>>>> ">" == HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> writes:
>
>>> I suspect another objects allocated remain while not collected.
>
> Thanks, you are correct.
>
> I used valgrind --tool=massif to find the problem.
>
> TRY_CATCH clears the cleanup chain, so making a cleanup in a TRY_CATCH
> and then trying to run or discard it outside the TRY_CATCH will not
> work; instead it leaks the cleanup.
>
> I am checking in the appended patch. It fixes both leaks. Verified
> with massif.
>
> Tom
>
> 2012-03-28 Tom Tromey <tromey@redhat.com>
>
> * python/py-inferior.c (infpy_read_memory): Remove cleanups and
> explicitly free 'buffer' on exit paths. Decref 'membuf_object'
> before returning.
>
After applying this patch, I no longer see any memory leak.
Again, thanks for your help, Tom.
(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
gc.collect()
(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
hat 28071 0.6 0.3 81964 12364 pts/0 S+ 09:41 0:00 /media/pub/repos/gdb/gdb/gdb ./testpro ./core.27403
(gdb) source ./testpro.py
(gdb) shell ps aux | grep gdb | grep -v grep
hat 28071 2.3 0.3 81968 12500 pts/0 S+ 09:41 0:00 /media/pub/repos/gdb/gdb/gdb ./testpro ./core.27403
(gdb) source ./testpro.py
(gdb) shell ps aux | grep gdb | grep -v grep
hat 28071 2.7 0.3 81968 12500 pts/0 S+ 09:41 0:01 /media/pub/repos/gdb/gdb/gdb ./testpro ./core.27403
(gdb) source ./testpro.py
sh(gdb) shell ps aux | grep gdb | grep -v grep
hat 28071 2.9 0.3 81968 12500 pts/0 S+ 09:41 0:02 /media/pub/repos/gdb/gdb/gdb ./testpro ./core.27403
Thanks.
HATAYAMA, Daisuke
prev parent reply other threads:[~2012-03-29 0:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 6:17 HATAYAMA Daisuke
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 [this message]
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=20120329.094856.310071246.d.hatayama@jp.fujitsu.com \
--to=d.hatayama@jp.fujitsu.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/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