R. David Murray added the comment:
Looking at the current buildbot history I don't see these errors any more. I'm
not sure how frequent they were, but I think I'll mark this as resolved and we
can reopen it if we see it again.
--
resolution: - invalid
stage: needs patch -
Charles-François Natali added the comment:
Here's another failure:
==
FAIL: test_interpreter_shutdown
(test.test_concurrent_futures.ProcessPoolShutdownTest)
--
R. David Murray added the comment:
Yes, it is a linux vserver VM. I would think we would want tests to not fail
in VMs, though, in this day and age.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19386
R. David Murray added the comment:
Also, unless people haven't been reporting other errors, these buildbots have
been stable up until recently, with the exception of the multiprocessing hangs
that plague all the buildbots as far as I know. (My impression could be
mistaken, though.)
Charles-François Natali added the comment:
Also, unless people haven't been reporting other errors, these buildbots have
been stable up until recently
Well, the fact that several tests - which were working just fine -
started failing randomly recently (like test_concurrent_futures,
R. David Murray added the comment:
What could cause a VM clock problem on a machine that hasn't been modified, but
the VMs have been rebooted recently (ie: it isn't stale state inside the VM
itself). Anything you can suggest I look at?
--
___
R. David Murray added the comment:
I'm going to reboot the host just to see if that makes any difference. It's
been up for 105 days.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19386
New submission from Christian Heimes:
The test seems to be unstable on some build bots:
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/5271/steps/test/logs/stdio
==
FAIL: test_interrupted_retry
Charles-François Natali added the comment:
This failure doesn't make sense: whether SIGALRM is delivered or not, epoll()
should time out after 2 seconds, not 105s.
What's more, here's another test_subprocess failure:
==
Antoine Pitrou added the comment:
Flaky VM clock perhaps?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19386
___
___
Charles-François Natali added the comment:
Flaky VM clock perhaps?
Yeah, thought about that, but here we see *exactly* the same value for
two time intervals (using time.monotonic()), computed over different
test suite runs. I'd expected something more erratic...
--
R. David Murray added the comment:
The only change on the buildbot for some months now was increasing the size of
the in-memory /tmp filesystem, which I did yesterday. That also involved a
reboot, though, and it is conceivable that there were software changes made
since the last reboot and
Charles-François Natali added the comment:
Could you try to run the test in a loop under strace (strace -ttTf) ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19386
___
13 matches
Mail list logo
