[issue26144] test_pkg test_4 and/or test_7 sometimes fail

Karthikeyan Singaravelan added the comment: I am closing this issue as duplicate as part of triaging adding issue34200 as superseder that reports the same error along with a PR and discussion. There have been no failures reported with respect to test_pkg after the fix was merged. Feel free

[issue26144] test_pkg test_4 and/or test_7 sometimes fail

Karthikeyan Singaravelan added the comment: I think this was fixed with https://bugs.python.org/issue34200 though the patch was not applied to 3.5 and 3.4 as they are in security bug fixes mode. Thanks -- nosy: +xtreak ___ Python tracker

[issue26144] test_pkg test_4 and/or test_7 sometimes fail

Changes by Serhiy Storchaka : -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker ___

[issue26144] test_pkg test_4 and/or test_7 sometimes fail

Martin Panter added the comment: I think I traced this to revision fbbf8b160e8d (Issue 9548, Python 3.4). Before that revision, I haven’t been able to produce the failures. Also, reverting that change in the current default branch seems to stop the failures. Attached is the patch that reverts

[issue26144] test_pkg test_4 and/or test_7 sometimes fail

Rose Ames added the comment: Reproduced. In four runs, one errored in test_4, one failed in test_7, and the other two did both. -- nosy: +superluser ___ Python tracker

[issue26144] test_pkg test_4 and/or test_7 sometimes fail

Rose Ames added the comment: redirecting stdout seems to reliably suppress both failures: $ ./python -m test -w test_pkg >foo $ cat foo [1/1] test_pkg 1 test OK. -- ___ Python tracker

[issue26144] test_pkg test_4 and/or test_7 sometimes fail

New submission from Martin Panter: It doesn’t always fail, and sometimes only one or the other test fails. Also, it seems to depend on the way the tests are run. I have never seen it fail with “python -m test -v”. Two commands where it does often fail for me: ./python -m test -w test_pkg