Fatal error on transport TCPTransport leads to AttributeError: 'NoneType' object has no attribute 'cancel'

[mjpieters]

• uvloop version: 0.12.2
• Python version: 3.7.3
• Platform: Linux
• Can you reproduce the bug with PYTHONASYNCIODEBUG in env?: Yes

I'm seeing the following error appear:

ERROR:asyncio 2019-06-26 16:31:00,938 Fatal error on transport TCPTransport
protocol: <uvloop.loop.SSLProtocol object at 0x7ff364a0cea8>
transport: <TCPTransport closed=False reading=False 0x562875e82178>
Traceback (most recent call last):
  File "uvloop/sslproto.pyx", line 574, in uvloop.loop.SSLProtocol._do_shutdown
  File "/usr/lib/python3.7/ssl.py", line 767, in unwrap
    return self._sslobj.shutdown()
ssl.SSLError: [SSL: KRB5_S_INIT] application data after close notify (_ssl.c:2609)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "uvloop/handles/stream.pyx", line 767, in uvloop.loop.__uv_stream_on_read_common
  File "uvloop/handles/stream.pyx", line 613, in uvloop.loop.UVStream._on_eof
  File "uvloop/sslproto.pyx", line 398, in uvloop.loop.SSLProtocol.eof_received
  File "uvloop/sslproto.pyx", line 578, in uvloop.loop.SSLProtocol._do_shutdown
  File "uvloop/sslproto.pyx", line 585, in uvloop.loop.SSLProtocol._on_shutdown_complete
AttributeError: 'NoneType' object has no attribute 'cancel'

This looks to be the same issue as aio-libs/aiohttp#3535 and python/cpython#13548, but with an added twist that uvloop's SSLProtocol implementation has a bug of its own. The attribute error is thrown because _shutdown_timeout_handle has not been set, and it is not set because _start_shutdown has not been called.

After verification that the issue is still present on master, I worked around this issue by testing for the handle in _on_shutdown_complete

cdef _on_shutdown_complete(self, shutdown_exc):
    if self._shutdown_timeout_handle is not None:
        self._shutdown_timeout_handle.cancel()

    # ...

[1st1]

Thanks for the bug report!

@fantix what do you think about this?

[fantix]

checking

@mjpieters Thanks for the verification! Your conclusion is correct, in the case when the peer closes the writing end of the underlying TCP connection without sending an SSL shutdown message, self._shutdown_timeout_handle would be None. The _on_shutdown_complete() didn't do sanity check because it is not None in other cases which I thought were all the cases.

Your fix is a good one, I'll write a test to cover the case.

[mjpieters]

@fantix do you need anything else from me to create a test for this still?

[fantix]

@mjpieters oh sorry I was distracted, yeah it'll be really nice if you can also provide a test. I'll only have time after next week. Appreciate you asked ❤️

[1st1]

I've just published https://github.com/MagicStack/uvloop/releases/tag/v0.14.0rc1. Please test. The final release will be published some time next week if RC1 is OK.