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_threaded_import fails with -j4 #59985
Comments
test_parallel_module_init() fails on Windows-64: ====================================================================== Traceback (most recent call last):
File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_threaded_import.py", line 125, in test_parallel_module_init
self.check_parallel_module_init()
File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_threaded_import.py", line 120, in check_parallel_module_init
self.assertFalse(errors)
AssertionError: [AttributeError("'module' object has no attribute 'randrange'",)] is not false |
The buildbot in question uses -j4, and I can reproduce this on Linux ./python -m test -uall -F -j4 -v test_threaded_import ====================================================================== Traceback (most recent call last):
File "/home/stefan/hg/cpython/Lib/test/test_threaded_import.py", line 131, in test_parallel_meta_path
self.check_parallel_module_init()
File "/home/stefan/hg/cpython/Lib/test/test_threaded_import.py", line 120, in check_parallel_module_init
self.assertFalse(errors)
AssertionError: [AttributeError("'module' object has no attribute 'randrange'",), AttributeError("'module' object has no attribute 'randrange'",)] is not false Ran 6 tests in 4.221s |
With |
No joy here either - currently at 704 successful runs and counting with Stefan's command line. $ uname -a
Linux lancre 3.5.1-1.fc17.x86_64 #1 SMP Thu Aug 9 17:50:43 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz
model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz
model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz
model name : Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz |
I can only reproduce this on a Core i7. Native OS is Debian Wheezy, $ cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz
model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz I can't reproduce it on a Core 2 Duo running Ubuntu natively. |
Up to 2279 runs without a failure here - yay for elusive hardware specific threading bugs :P I'll leave it running overnight and see what happens. |
I can also reproduce it on the Core 2 machine with a ridiculuously diff --git a/Lib/test/regrtest.py b/Lib/test/regrtest.py
--- a/Lib/test/regrtest.py
+++ b/Lib/test/regrtest.py
@@ -198,6 +198,8 @@
except ImportError:
multiprocessing = None
+sys.setswitchinterval(0.00000001)
+
# Some times __path__ and __file__ are not absolute (e.g. while running from
# Lib/) and, if we change the CWD to run the tests in a temporary dir, some |
Oh, and as usual, my machines have all CPUs at 100% load. |
So this was a random one-off (hardly even intermittent) failed test that passed on the retry. Ah, threads. Is there an easy way to find all other failures in test_threaded_import in the past, for this and for all buildbots? Do we have information about load during tests? Is there an easy way to run the test suite under load on a build bot? With a large enough sample size we can make more sense of this. For instance, do failures predate the addition of per-module import locks or the importlib migration in 3.3? Are failures limited to particular platforms? Is the problem load related? BTW, test_threaded_import had another (different) failure a week ago on FreeBSD: bpo-15599. |
(sorry, only saw the first couple messages) |
On the i7 machine with hyper-threading the issue occurs since The tests also got slower: 3430d7329a3b: $ time ./python -m test -uall -v test_threaded_import real 0m3.195s edb9ce3a6c2e: $ time ./python -m test -uall -v test_threaded_import real 0m24.032s Here most of the time is spent in test_parallel_meta_path. DISCLAIMER: This machine runs Debian Wheezy, which is not |
Ok, I can now reproduce with setswitchinterval(). Here is a patch. There was a race between putting the new module in sys.modules and setting its __initializing__ attribute, so now __initializing__ is set before putting the module in sys.modules. Also, there was another race when retrieving a module lock from the locks dict (the weakref could be destroyed between the __contains__ test and the actual fetch). |
Didn't patch it in to evaluate the surrounding code, but otherwise the patch LGTM. |
Looks good to me. Please commit to default and I'll cherry-pick to rc2. |
If possible I would like to wait for Stefan's confirmation that it fixes the failures for him. |
Sure. |
Nice, on the finicky i7 machine test_threaded_import is fixed. I'm getting another error in test_importlib, both with and without $ ./python -m test -uall -F test_importlib
[ 1] test_importlib
test test_importlib failed -- Traceback (most recent call last):
File "/home/stefan/hg/cpython/Lib/test/test_importlib/test_locks.py", line 80, in test_deadlock
self.assertEqual(results.count((True, False)), 1)
AssertionError: 2 != 1 1 test failed: |
Please do. Thanks! |
New changeset 7fa6336e9864 by Antoine Pitrou in branch 'default': |
Looks fixed! |
Now picked into 3.3.0 release clone as 85070f284fd2. |
New changeset 85070f284fd2 by Antoine Pitrou 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: