Example (minimal version of https://github.com/python-trio/trio/issues/425): ----- async def open_file(): pass async def main(): async with open_file(): # Should be 'async with await open_file()' pass coro = main() coro.send(None) ----- Here we accidentally left out an 'await' on the call to 'open_file', so the 'async with' tries to look up 'CoroutineType.__aexit__', which obviously doesn't exist, and the program crashes with an AttributeError("__aexit__"). Yet weirdly, this doesn't trigger a warning about 'open_file' being unawaited. It should! Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to DECREF the object.

> Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to DECREF the object. Nope, that doesn't seem to be it. This version prints "refcount: 2" twice, *and* prints a proper "was never awaited" warning: ----- import sys async def open_file(): pass async def main(): open_file_coro = open_file() print("refcount:", sys.getrefcount(open_file_coro)) try: async with open_file_coro: pass except: pass print("refcount:", sys.getrefcount(open_file_coro)) coro = main() try: coro.send(None) except: pass

Looking at the ceval code, I think Yury's theory is plausible, and we may also be leaving the interpreter's internal stack in a dubious state. Things then get cleaned up if you wrap the async with in a try/except or try/finally: ============== >>> async def try_main(): ... try: ... async with open_file(): ... pass ... finally: ... pass ... >>> try_main().send(None) sys:1: RuntimeWarning: coroutine 'open_file' was never awaited Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in try_main AttributeError: __aexit__ ============== Unfortunately for that theory, adding braces and "Py_DECREF(POP());" to the relevant error handling branch *doesn't* fix the problem. I also found another way to provoke similar misbehaviour without async with: ========== >>> async def open_file(): ... pass ... >>> open_file() <coroutine object open_file at 0x7f92fe19c548> >>> _ <coroutine object open_file at 0x7f92fe19c548> >>> 1 __main__:1: RuntimeWarning: coroutine 'open_file' was never awaited 1 >>> open_file() <coroutine object open_file at 0x7f92fe19c548> >>> del _ Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name '_' is not defined >>> _ <coroutine object open_file at 0x7f92fe19c548> >>> 1 1 >>> _ 1 >>> ==========

Changing async def main(): async with open_file(): pass to async def main(): c = open_file() async with c: pass also makes it print the warning :) Also I've made a test out of this snippet and running tests in refleak mode shows that there's indeed no refleak here.

The difference between these two functions is two extra opcodes: STORE_FAST/LOAD_FAST before BEFORE_ASYNC_WITH. With them we have a warning.

So refactoring it into "c = open_file(); async with c" just prolongs the life of the coroutine so that it's GCed outside of WITH_CLEANUP_START/WITH_CLEANUP_FINISH block. Something weird is going on in that block.

Ah, we should never really get to WITH_CLEANUP_START; the exception should be raised in BEFORE_ASYNC_WITH

So the problem was that _PyGen_Finalize wasn't issuing any warnings if there's any error set in the current tstate. And in Nathaniel's case, the current error was an AttributeError('__aexit__'). This check is weird, because right before raising the warning, we call PyErr_Fetch to temporarily reset the current exception if any, specifically to raise the warning :) The PR just removes the check. Unless I'm missing something this should fix the issue.

Well, I feel silly then: bpo-32605

Ah, and in my REPL example, the NameError was pending when the internal result storage was getting set back to None. I'm not sure I even knew the "Don't complain when an exception is pending" check existed, so it would have taken me a long time to find that.

I knew about that "if", but it never fully registered to me why it's there and what it is protecting us from ;) So I had to debug half of ceval loop before I stumbled upon it again ;)

 New changeset 2a2270db9be9bdac5ffd2d50929bf905e7391a06 by Yury Selivanov in branch 'master': bpo-32703: Fix coroutine resource warning in case where there's an error (GH-5410) https://github.com/python/cpython/commit/2a2270db9be9bdac5ffd2d50929bf905e7391a06 

Merged; closing this issue.