gh-126083: Fix a reference leak in asyncio.Task when reinitializing with new non-None context

[Nico-Posada]

Fix for ref leak described in #126083.

This is my first CPython PR so feedback is appreciated :)

• Issue: Bug: Reference leak in _asyncio_Task___init___impl in _asynciomodule.c #126083

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[willingc]

Adding @sobolevn to the reviews since they may have some context from looking at the issue.

@Nico-Posada Congrats on working on tackling your first contribution.

[sobolevn]

Do we really need 10000 iterations to find a leak?

[ZeroIntensity]

Well, maybe not 10000, but finding leaks is certainly easier with more iterations. Maybe 1000 should do?

[Nico-Posada]

I changed it to 5, the bug would be triggered every time so with a low amount you should still be able to see the ref leak.

[willingc]

Seeing this output when running tests locally:

test_proper_refcounts (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests.test_proper_refcounts) ... /Users/willingc/Code/cpython/Lib/unittest/case.py:606: RuntimeWarning: coroutine 'coroutine_function' was never awaited
  result = method()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
ok

[sobolevn]

To fix the warning :)

[willingc]

Thanks for the detailed review @sobolevn

[Nico-Posada]

Ah that's annoying, I thought I was signed in to my GitHub account when I made that commit. Is there any way to revert this to change ownership? Not sure if I can resign the CLA with that account.

[ZeroIntensity]

I've done that before too, yeah. I think the only way is to overwrite the commit locally and then force push it.

[sobolevn]

question: do we expect this exception in all cases? if so, use with self.assertRaisesRegex(RuntimeError, 'break'):

[Nico-Posada]

So update it to be this?

for _ in range(5):
    with self.assertRaisesRegex(RuntimeError, 'break'):
        task.__init__(coro, loop=loop, context=obj, name=Break())

[picnixz]

FTR: In order to catch the correct exception in #126120, I used a custom exception + a special argument so that I'm sure that I catch and expect the correct one (and not just a random one because of something else). So what I did was something like:

# what I want to catch
def foo():
	raise ReachableCode(1)

# what I don't want to catch yet
def bar():
	raise ReachableCode(2)

# where I call the thing I want to catch
with self.assertRaises(ReachableCode) as cm:
	something_that_calls_foo()
self.assertEqual(len(cm.exception.args), 1)
self.assertIs(cm.exception.args[0], 1)

I find this pattern quite good (maybe a bit too exhaustive) because I can really see what I'm catching.

[Nico-Posada]

I like the idea of the ReachableCode exception class, but I still think it's easier and more readable to just do

with self.assertRaisesRegex(ReachableCode, 'str here'):
    ...

and use a string in the arg instead of an int

[picnixz]

I think I'll go with that as well to simplify the tests on my side (but not today).

[ZeroIntensity]

LGTM as well

[sobolevn]

Thanks you! Congrats on your first CPython PR! 🎉

[miss-islington-app]

Thanks @Nico-Posada for the PR, and @sobolevn for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-126229 is a backport of this pull request to the 3.13 branch.

[bedevere-app]

GH-126230 is a backport of this pull request to the 3.12 branch.