The following test of test_asyncio failed once. I didn't check if it failed more than once on this buildbot.

The cleanup code is not safe, it should handle errors correctly, so following tests would not fail.

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/5421/steps/test/logs/stdio

======================================================================
ERROR: test_close (test.test_asyncio.test_unix_events.FastChildWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 662, in _do_waitpid_all
    callback, args = self._callbacks.pop(pid)
KeyError: 7673

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_asyncio/test_unix_events.py", line 723, in setUp
    self.watcher = self.create_watcher(self.loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_asyncio/test_unix_events.py", line 1466, in create_watcher
    return unix_events.FastChildWatcher(loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 596, in __init__
    super().__init__(loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 474, in __init__
    self.set_loop(loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 498, in set_loop
    self._do_waitpid_all()
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 665, in _do_waitpid_all
    with self._lock:
AttributeError: 'FastChildWatcher' object has no attribute '_lock'


Following tests fail like that:

======================================================================
FAIL: test_create_watcher (test.test_asyncio.test_unix_events.FastChildWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_asyncio/test_unix_events.py", line 718, in setUp
    assert ChildWatcherTestsMixin.instance is None
AssertionError

I'll ask Anthony Baire (the author of the new child watcher code) to look into this. Thanks for reporting this!

Also reproduced on "x86 Ubuntu Shared 3.x" buildbot.

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9012/steps/test/logs/stdio

======================================================================
ERROR: test_close (test.test_asyncio.test_unix_events.FastChildWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/asyncio/unix_events.py", line 662, in _do_waitpid_all
    callback, args = self._callbacks.pop(pid)
KeyError: 21303

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/test_unix_events.py", line 723, in setUp
    self.watcher = self.create_watcher(self.loop)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/test_unix_events.py", line 1466, in create_watcher
    return unix_events.FastChildWatcher(loop)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/asyncio/unix_events.py", line 596, in __init__
    super().__init__(loop)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/asyncio/unix_events.py", line 474, in __init__
    self.set_loop(loop)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/asyncio/unix_events.py", line 498, in set_loop
    self._do_waitpid_all()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/asyncio/unix_events.py", line 665, in _do_waitpid_all
    with self._lock:
AttributeError: 'FastChildWatcher' object has no attribute '_lock'

Attached patch should fix this issue. BaseChildWatcher constructors calls set_loop() which calls _do_waitpid_all(). The problem is that _do_waitpid_all() is called before FastChildWatcher own attributes are set.

Hmm...  That fix works, and if you're concerned about the buildbots, by all means check it in.

But I think the root cause is a poor API for initializing ChildWatchers.  This is currently done at the end of __init__() -- it calls self.set_loop() which is implemented by the subclass.

I think the right fix is to change the protocol to separate out the constructor from the set_loop() call (which also isn't a great name, since it does so much more -- maybe it can be called link_loop()?).   This is more cumbersome (esp. for the tests), but it really rubs me the wrong way that you have to to initialize the subclass before initializing the base class.

I confirm the fix.

It is clear that the separation between BaseChildWatcher and its subclasses is far from ideal. The first implementation was clean, but as the patch evolved interactions got complex to the point that BaseChildWatcher should not be considered as an API but rather as implementation details for the two other classes (eg. .add_child_handler() is implemented in subclasses whereas .remove_child_handler() is in the base class). At least it should be renamed as _BaseChildWatcher to make that clear.

For set_loop, another possible name is 'attach_loop' (like in the doc string actually)

TBH the test structure is also rather fragile.  I need to think about it more; the global state to hold the current test instance smells, as do the various class-level functions (waitpid(), WIFEXITED() etc.) that aren't methods but used as mock functions.  The huge piles of mock.patch decorators should have tipped me off during the review, but I was more focused on the implementation instead of on the tests. :-(

The smallest fix to prevent one breaking test from breaking all following tests is just to remove the assert.  The next smallest fix is to use addCleanup() instead of tearDown() to reset ChildWatcherTestsMixin.instance.  The next fix would be huge (refactor the tests completely) and I don't want to go there.

Anthony, can you come up with a fix along the lines you suggested?  You can submit this to the Tulip repo first (let me review it).

New changeset 8e0eeb4cc8fa by Guido van Rossum in branch 'default':
asyncio: Temporary fix by Victor Stinner for issue 19566.
http://hg.python.org/cpython/rev/8e0eeb4cc8fa

I pushed Victor's temporary patch so the buildbots can have peace.

I put a cleaner patch here:

https://codereview.appspot.com/26220043/

> Hmm...  That fix works, and if you're concerned about the buildbots, by all means check it in.
> (...)
> I pushed Victor's temporary patch so the buildbots can have peace.

Yes, I'm concerned by buildbots, I would like to check if my last
changes did not introduce any regression. This week, there is a lot of
noise: many false positive related to networks and various other bugs.

(So thanks for having applied my fix.)

New changeset eb42adc53923 by Guido van Rossum in branch 'default':
asyncio: Fix from Anthony Baire for CPython issue 19566 (replaces earlier fix).
http://hg.python.org/cpython/rev/eb42adc53923

I think the issue has been fixed, thanks.