- 22 Dec, 2017 5 commits
-
-
Jason Madden authored
Disable PyPy+libuv on Windows again, still some very strange errors there. But PyPy+libuv on darwin/posix works, and CPython3.6 Windows works. Perhaps the issue is the 32-bit pypy on windows and the way it adjusts socket.fileno()?
-
Jason Madden authored
-
Jason Madden authored
Hopefully solve the test__os issue. It turned out to be that calling uv_close at random GC times is a very bad idea under libuv. See the comment. Try enabling pypy+libuv on posix and windows; it's working on darwin for me.
-
Jason Madden authored
-
Jason Madden authored
By closing them when we're done, we can remove reliance on GC to clean up multiplexed watchers and solve problems for PyPy and Windows (and probably eventually simplify the handle cleanup we were doing.) This makes many more tests on PyPy pass on Darwin; down from a score of failures to about 4, but a baffling 4. test__os:TestOS_nb times out; investigation shows that both the read and write sides of the pipe are waiting on events, both are in libuv, and the write side should be writable, but it's not getting an event. Not clear why this is. I also see it with CPython 3.6, and I don't think I did before.
-
- 15 Dec, 2017 4 commits
-
-
Jason Madden authored
-
Jason Madden authored
Support libuv under CPython 3.6 on Windows
-
Jason Madden authored
First the crash report: ``` testInterruptedRecvmsgTimeout (__main__.InterruptedRecvTimeoutTest) ... Traceback (most recent call last): File "/home/travis/build/gevent/gevent/src/gevent/_ffi/loop.py", line 83, in python_callback def python_callback(self, handle, revents): File "/home/travis/build/gevent/gevent/src/greentest/3.6/test_socket.py", line 3698, in <lambda> lambda signum, frame: 1 / 0) ZeroDivisionError: division by zero Fri Dec 15 16:09:36 2017 ok testInterruptedSendTimeout (__main__.InterruptedSendTimeoutTest) ... Fatal Python error: ffi.from_handle() detected that the address passed points to garbage. If it is really the result of ffi.new_handle(), then the Python object has already been garbage collected Thread 0x00002b26d4c01700 (most recent call first): File "/home/travis/build/gevent/gevent/src/gevent/_threading.py", line 152 in wait File "/home/travis/build/gevent/gevent/src/gevent/_threading.py", line 436 in get File "/home/travis/build/gevent/gevent/src/gevent/threadpool.py", line 200 in _worker Thread 0x00002b26d4a00700 (most recent call first): File "/home/travis/build/gevent/gevent/src/gevent/_threading.py", line 152 in wait File "/home/travis/build/gevent/gevent/src/gevent/_threading.py", line 436 in get File "/home/travis/build/gevent/gevent/src/gevent/threadpool.py", line 200 in _worker Current thread 0x00002b26cc7b2a00 (most recent call first): File "/home/travis/build/gevent/gevent/src/gevent/_ffi/loop.py", line 178 in python_stop File "/home/travis/build/gevent/gevent/src/gevent/libuv/loop.py", line 289 in run File "/home/travis/build/gevent/gevent/src/gevent/hub.py", line 688 in run ``` The main problem turned out to be the way in which libuv reports signals at random times, much worse than the way libev does. This led to callback functions unexpectedly returning 0, because that's the default for an unhandled exception or an onerror handler that returns None. That in turn led to calls to python_stop that we weren't expecting using a handle that had already been deallocated. The fix is to both be defensive about what handles we try to use, and to be more explicit about our error returns.
-
Jason Madden authored
Disable pypy on appveyor again because it takes too long. I need to make sure it runs on POSIX first.
-
- 14 Dec, 2017 3 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
I solved the test_ftplib.py windows failures locally by more careful handling of lifetimes of io watchers: they should be disposed when the fileno is. I investigated a more drastic approach using new watchers entirely every time we restart, but it doesn't seem necessary, at least on CPython (I can't even run PyPy+libuv locally on darwin though, so there are more problems lurking there).
-
- 13 Dec, 2017 7 commits
-
-
Jason Madden authored
All tests are passing locally after fixing a GC-cycle related issue in the io watcher that kept the wrong socket watchers alive. This should probably be generalized to all watchers on all FFI platforms.
-
Jason Madden authored
Attempt to fix (or workaround) test__socket.py on Windows
-
Jason Madden authored
-
Jason Madden authored
It runs locally for me on Win10/Py3.6 with both libev and libuv. It had been sometimes failing since 2016-02 for 2.7 and 2016-04 for 3.5. Here's the comment in the code indicating what I tracked down. Note that the changes are more of a workaround than a true fix: XXX: On Windows (at least with libev), if we have a cleanup/tearDown method that does 'del self.listener' AND we haven't sometime previously closed the listener (while the test body was executing) we tend to sometimes see hangs when tests run in succession; notably test_empty_send followed by test_makefile produces a hang in test_makefile when it tries to read from the client_file, because the accept() call in accept_once has not yet returned a new socket to write to. The cause *seems* to be that the listener socket in both tests gets the same fileno(); or, at least, if we don't del the listener object, we get a different fileno, and that scenario works. Perhaps our logic is wrong in libev_vfd in the way we use _open_osfhandle and determine we can close it? Additional note: Possibly libuv doesn't suffer from this since it takes the SOCKET object directly? I didn't fully test that situation, but libuv tests were failing and are now passing.
-
Jason Madden authored
-
Jason Madden authored
Add and fix test_ftplib.py and test_asyncore.py for 3.6.
-
Jason Madden authored
-
- 12 Dec, 2017 3 commits
-
-
Jason Madden authored
-
Jason Madden authored
Test on 3.6.3 on Travis; appveyor was already there.
-
Jason Madden authored
-
- 11 Dec, 2017 5 commits
-
-
Jason Madden authored
Use setuptools to build libuv, and enable it on Windows (especially for PyPy)
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
Let PyPy fail on Appveyor for now. Also bump Travis PyPy to 5.9.0 because I can't reproduce the test__makefile_ref failure locally on 5.9.0. Fixes #1029.
-
- 09 Dec, 2017 3 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
- 08 Dec, 2017 10 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
Successful test with CPython 3.5 on Windows 10; have to elide getaddrinfo and getnameinfo because they won't link.
-
Jason Madden authored
Tweak test for random ImportWarning from Python 3: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
-
Jason Madden authored
Use setuptools to build libuv. This should be much simpler, especially on windows, at the cost of manually keeping up with link arguments and file deps.
-
Jason Madden authored
-
Jason Madden authored
-