[
https://issues.apache.org/jira/browse/THRIFT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688119#action_12688119
]
Jérémie BORDIER commented on THRIFT-391:
----------------------------------------
I'm not a python c-api pro, but the patch looks obvious and correct. I think
the Py_INCREF / DECREF should be kept here to avoid unsafe garbage collection
in multithreaded environment. So, lgtm, +1.
> 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.
