New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_asyncio unstable in refleak mode #66302
Comments
test_asyncio doesn't give usable results when looking for refleaks: $ ./python -m test -R 2:4 test_asyncio
[1/1] test_asyncio
beginning 6 repetitions
123456
......
test_asyncio leaked [212, -106, 265, -6360] references, sum=-5989
test_asyncio leaked [59, -29, 76, -1799] memory blocks, sum=-1693
1 test failed:
test_asyncio |
Was this always so or did it recently start? Victor has made a ton of changes. Anyway, I imagine there may be some objects stuck in cycles and the collection may not happen until a random later time, and the tests do timing-specific stuff so the number of objects created and deleted varies per run. Perhaps adding some well-aimed gc.collect() calls to some tearDown() methods would make this go away? |
I think I'm to blame for exposing this in 4f9f7e0fe1fd. I have a theory on why that exposed it; I think regrtest is holding an extra reference to the TestSuite in runtest_inner since it is using a different branch now that test_asyncio doesn't have a test_main function. |
It may be related to the issue bpo-17911. |
I checked: it is. The strange reference count can be seen with a single test. Example: $ ./python -m test -R 3:3: -m test_default_exc_handler_coro test_asyncio
[1/1] test_asyncio
beginning 6 repetitions
123456
......
test_asyncio leaked [53, 53, -106] references, sum=0
test_asyncio leaked [15, 15, -30] memory blocks, sum=0
1 test failed:
test_asyncio This test uses a coroutine which raises an exception. The exception is stored in a Task object. But the exception contains also a traceback which indirectly creates a reference cycle. For example, the zero_error_coro() coroutine of the test uses the free variable "self". It's very difficult to find all objects of a reference cycle. We can try to break some cycles, it's already done Task._step() which sets self to None, but it's a waste of time. IMO the correct fix is to not store frame objects in an exception: see the issue bpo-17911. |
Le 30/07/2014 06:08, STINNER Victor a écrit :
regrtest calls gc.collect(). |
I checked on my theory, and removing the extra reference to 'tests' from the runtest_inner scope fixes it for me: $ python -m test -R 3:3: test_asyncio
Running Debug|Win32 interpreter...
[1/1] test_asyncio
beginning 6 repetitions
123456
......
1 test OK. Here's the patch. |
New changeset 9bca86812857 by Zachary Ware in branch '3.4': New changeset 7bc53cf8b2df by Zachary Ware in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: