-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak when calling list(...) on OrderedDict #1718
Comments
Thanks for the well-prepared report. I was able to reproduce the problem using the latest development version. |
The underlying cause of this problem is that the conversion of an object (here an After the runtime shutdown, the dynamic type for I have not seen the code responsible for the call site cache management, but from reading the docs of the DLR I vaguely remember that the cache site is limited (in number of entries, not memory size). Therefore those stale dispatch rules will eventually get replaced by newer ones, so technically it is not a memory leak, more like memory swelling. Indeed, if I run the provided example, say 500 times, the memory footprint reaches a sort of a plateau around 2GB. Unfortunately, Ideally, those dynamic calls would be done in a runtime-scope context. Unfortunately, IronPython does not have the runtime-scope context; the choice is either the static global (default) context, or the actual (module) context. Perhaps the context of the |
Description
There is a memory leak when calling the list function with an OrderedDict. Even after the runtime has been shut down, objects of type PythonGetMemberBinder, PythonType, FunctionDefinition, FunctionCode etc. remain referenced and will not be garbage collected.
Steps to Reproduce
(Repro project available here: https://github.com/spkl/IronPythonMemoryRepro)
MyMethod
function.Expected behavior: The memory footprint is stable. (For reference: After the first execution, it is ~50MB).
Actual behavior: The memory footprint exceeds 300 MB after 50 repetitions. Forcing a garbage collection does not change it significantly. (With a larger, more complex example, we have observed ~600 MB of additional, uncollectable memory after 30 script executions.)
Workaround: Instead of
for v in list(od.values()):
, usefor v in [x for x in od.values()]
orfor v in od.values():
.Versions
The issue is reproducible with both 3.4.0 and 3.4.1.
The text was updated successfully, but these errors were encountered: