* Add _winapi.GetProcessHandleCount() * regrtest now also checks for leak of Windows handles * Add an unit test in test_regrtest Co-Authored-By: Richard Oudkerk <shibturn@gmail.com>
|
I'm running tests with "python -m test -j6 -R 2:3 -r" and it seems like some tests are failing randomly :-/ Example: "test_cmd_line leaked [1, 0, 0] handles, sum=1". Maybe regrtest is too strict. |
Detect a leak only if all runs leaked at least 1 handle to avoid false positives.
|
I ran "python -m test -j6 -R 2:3 -r" with the second commit "Make regrtest less strict". 10 tests failed:
Tests not always failed because of leaks, but I didn't have time yet to re-run these tests. I will do it later. |
Unrelated to this PR: the test is fragile, see for example https://bugs.python.org/issue33868
I'm investigating this issue, but there is already one open issue: https://bugs.python.org/issue32710
Unrelated to this PR, and again, I failed to reproduce the issue. Maybe a race condition.
Fixed by my PR #7843 (not merged yet)
Unrelated to this PR, and again, I failed to reproduce the issue. Maybe a race condition.
I confirm that I fail to reproduce the leak. Maybe a race condition.
I reproduced the leak. I'm running test.bisect on it.
Unrelated to this PR, and again, I failed to reproduce the issue. Maybe a race condition.
Oh. Running the test alone without -R 3:3 also fails. |
Oh, I confirm that it's exactly the same bug: test.test_asyncio.test_events.ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving leaks memory blocks (not handles!). |
I found a bug: https://bugs.python.org/issue33929 |
Ok, it's also a known issue: https://bugs.python.org/issue32942 |
|
Oh, test_multiprocessing_spawn is still not good, even with my PR 7921: |
I wrote a fix: PR 7966. Using this fix, test_multiprocessing_spawn now doesn't leak handles anymore! |
I created https://bugs.python.org/issue33977 |
Co-Authored-By: Richard Oudkerk shibturn@gmail.com
https://bugs.python.org/issue18174