On Sat, 8 Mar 2014 23:16:07 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 8 March 2014 23:01, Victor Stinner <victor.stinner at gmail.com> wrote:
> > 2014-03-08 12:45 GMT+01:00 Antoine Pitrou <solipsis at pitrou.net>:
> >>> Attached script: never_deleted2.py, it's almost the same but it
> >>> explains better the problem. The script creates MyObject and Future
> >>> objects which are never deleted. Calling gc.collect() does *not* break
> >>> the reference cycle (between the future, the exception, traceback and
> >>> frames). Stopping the event loop does not remove Future nor MyObject
> >>> objects. Only exiting Python does remove the Future object.
> >>
> >> So clearly the coroutine must be kept alive by something.
> >
> > It's a reference cycle. Something like that:
> >
> > Future -> Exception -> Traceback -> Frames -> Local variables ->
> > {Future, MyObject}
>
> It seems unlikely we could have an uncollectable reference cycle that
> doesn't end up in gc.garbage. Are you sure there are no external
> references to one of the objects in the cycle, thus keeping the whole
> thing alive?
Ok, it's actually quite trivial. The whole chain is kept alive by the
"fut" global variable. If you arrange for it to be disposed of:
fut = asyncio.Future()
asyncio.Task(func(fut))
del fut
[etc.]
then the problem disappears: as soon as gc.collect() happens, the
MyObject instance is destroyed, the future is collected, and the
future's traceback is printed out.
Regards
Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4