Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix leak of iopub object in activity monitoring #3424
After analyzing various leaked items when running either Notebook or
Although this ends up creating a wrapper around the same port, the
added a commit
this pull request
Mar 14, 2018
referenced this pull request
Mar 14, 2018
I don't immediately see why this would result in a leak; the kernel object itself is deleted shortly afterwards (the
What am I missing?
@takluyver - thanks for the response. I agree that its quite non-obvious. However, w/o this statement, the iopub object wrapper created here will not be garbage collected - with a new (leaked) instance persisted across each subsequent kernel cycle.
I found this and the two PRs (360, 361) submitted to jupyter_client via use of
However, since this leak was found prior to the resolution to the IOLoopKernelManager leak (via PR 361) then I suppose the change may not be required - although, in my opinion, is good practice. I didn't go and back out this change after breaking the circular references that were preventing the leak in 361.
Hmm - I just commented out this change (and running with all other fixes in place) and see the iopub object and the kernel manager instance leaks return. I don't see an obvious circular reference introduced by