[issue19432] test_multiprocessing_fork failures

2013-10-29 Thread Stefan Krah 

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):
  File /home/stefan/hg/master3/Lib/threading.py, line 921, in _bootstrap_inner
self.run()
  File /home/stefan/hg/master3/Lib/threading.py, line 869, in run
self._target(*self._args, **self._kwargs)
  File /home/stefan/hg/master3/Lib/test/_test_multiprocessing.py, line 1152, 
in task
self.f(*self.args)
  File /home/stefan/hg/master3/Lib/test/_test_multiprocessing.py, line 1382, 
in _test_default_timeout_f
barrier.wait()
  File /home/stefan/hg/master3/Lib/threading.py, line 616, in wait
self._wait(timeout)
  File /home/stefan/hg/master3/Lib/threading.py, line 653, in _wait
self._break()
  File /home/stefan/hg/master3/Lib/threading.py, line 702, in _break
self._cond.notify_all()
  File /home/stefan/hg/master3/Lib/threading.py, line 359, in notify_all
self.notify(len(self._waiters))
  File /home/stefan/hg/master3/Lib/threading.py, line 342, in notify
waiters_to_notify = _deque(_islice(all_waiters, n))
RuntimeError: deque mutated during iteration

FAIL


==
FAIL: test_default_timeout 
(test.test_multiprocessing_fork.WithThreadsTestBarrier)
--
Traceback (most recent call last):
  File /home/stefan/hg/master3/Lib/test/_test_multiprocessing.py, line 1393, 
in test_default_timeout
self.assertEqual(len(results), barrier.parties)
AssertionError: 4 != 5

--

--
messages: 201624
nosy: skrah
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork failures

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19432
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19432] test_multiprocessing_fork failures

2013-10-29 Thread Stefan Krah 

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 tracker rep...@bugs.python.org
http://bugs.python.org/issue19432
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19432] test_multiprocessing_fork failures

2013-10-29 Thread Richard Oudkerk 

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 seen this failure?  Did it happen on a buildbot?  Was there 
a lot of other activity on the system at the time?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19432
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19432] test_multiprocessing_fork failures

2013-10-29 Thread Stefan Krah 

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_multiprocessing_fork no longer fails.

--
resolution:  - works for me
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19432
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com