[
https://issues.apache.org/jira/browse/THRIFT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shigin updated THRIFT-391:
------------------------------------
Attachment: thrift-fastbinary-leak.patch
It seems the patch solves the problem.
Can anyone review it? David, I think we can solve the problem by eliminating
Py_INCREF (there is your TODO), but i am not guru of python c-api.
> Memory leak in fastbinary
> -------------------------
>
> Key: THRIFT-391
> URL: https://issues.apache.org/jira/browse/THRIFT-391
> Project: Thrift
> Issue Type: Bug
> Components: Library (Python)
> Environment: Linux 2.6.21 (Debian)
> Reporter: Garrett Smith
> Fix For: 0.1
>
> Attachments: testmem.tar.gz, thrift-fastbinary-leak.patch
>
>
> When a struct has a map member, fastbinary.binary_encode leaks memory.
> Use testmem.tar.gz app to recreate the problem.
> {code}
> # tar xzf testmem.tar.gz
> # cd testmem
> # ./testmem fast
> {code}
> As this is running, use top or pidstat to view the memory consumed by the
> process. Hit CTRL-C to stop. On my system it steadily increases.
> To compare the results using the 'default' encoding technique (using pure
> Python TBinaryProtocol), run testmem as follows:
> {code}
> # ./testmem default
> {code}
> Note (again, using top, pidstat, etc.) that the memory used is constant.
> It appears that the 'map' member triggers this. E.g. string, int members do
> not cause the leak.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.