This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steven.daprano
Recipients bup, docs@python, eric.smith, steven.daprano
Date 2018-06-10.00:24:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1528590302.99.0.592728768989.issue33814@psf.upfronthosting.co.za>
In-reply-to
Content
I decided to risk this "catastrophic" leak, and ran this:

py> x = leaks()
py> x
((2, 3), <weakref at 0xb7a1998c; to 'function' at 0xb789826c (f)>, 24)
py> import gc
py> gc.collect()
22
py> x
((2, 3), <weakref at 0xb7a1998c; dead>, 24)


so I think Eric is correct, it is just a garbage collection issue. Possibly a bug, possibly normal behaviour. I don't think it is a documentation bug, if it is a bug at all it might be a garbage collection bug.

But I really don't know, because I don't understand what Dan thinks is the memory leak here or why it happens. I *think* Dan might be referring to the fact that each time you call leaks(), there's one extra reference to itertools.repeat.

Dan, if you can confirm that's the leak you are referring to, we would have a better chance of deciding whether it is a bug and if so if it is specific to exec.
History
Date User Action Args
2018-06-10 00:25:05steven.dapranosetrecipients: + steven.daprano, eric.smith, docs@python, bup
2018-06-10 00:25:02steven.dapranosetmessageid: <1528590302.99.0.592728768989.issue33814@psf.upfronthosting.co.za>
2018-06-10 00:25:02steven.dapranolinkissue33814 messages
2018-06-10 00:24:58steven.dapranocreate