IronLanguages / IronLanguages/ironpython3
Memory leak when calling list(...) on OrderedDict
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 2.8k
- Forks
- 316
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 1
Description
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)
- In a .NET 6 program, create a ScriptEngine and ScriptScope.
- Create a ScriptSource from a file containing the following code:
import collections
def MyMethod(dummy):
od = collections.OrderedDict()
for i in range(100):
od[i] = []
for v in list(od.values()):
continue
return dummy
- Execute the ScriptSource.
- Call the
MyMethodfunction. - Shut down the engine.
- Repeat this 50 times.
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()):, use for v in [x for x in od.values()] or for v in od.values():.
Versions
The issue is reproducible with both 3.4.0 and 3.4.1.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the linked IronPythonMemoryRepro with the .NET 6 steps and compare list(od.values()) with the documented workarounds. Trace references to PythonGetMemberBinder, PythonType, FunctionDefinition, and FunctionCode after engine shutdown; done means repeated executions keep memory stable and those objects can be collected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, python
- Domain
- backend, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100