Stefan Krah added the comment:
I've seen the failure very often, without any particular load.
Now I noticed that during test_tools there were several ksoftirqd
processes consuming 20% CPU on 4 cores. That seemed unusual to
me, so I followed the advice of a certain MIT koan and rebooted.
test_m
Richard Oudkerk added the comment:
This is a test of threading.Barrier rather than anything implemented directly
by multiprocessing.
Tests which involve timeouts tend to be a bit flaky. Increasing the length of
timeouts usually helps, but makes the tests take even longer.
How often have you
Stefan Krah added the comment:
The issue is probably different from #19227, since it already occurs
with 4e79c3ae8a12.
--
components: +Extension Modules
nosy: +sbt
stage: -> needs patch
type: -> behavior
versions: +Python 3.3, Python 3.4
___
Python
New submission from Stefan Krah:
I'm getting the following test_multiprocessing_fork failures on Debian
Wheezy. Perhaps this is related to #19227:
test_default_timeout (test.test_multiprocessing_fork.WithThreadsTestBarrier)
... Exception in thread Thread-344:
Traceback (most recent call last)
