Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSilently closes UDP socket #338
Open
Comments
spumer
added a commit
to spumer/source-query-proxy
that referenced
this issue
Jun 17, 2020
App can start infinity waiting on silently closed socket. This behaviour possible due uvloop internal bug MagicStack/uvloop#338
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PYTHONASYNCIODEBUGin env?: Yesuvloop silently closes UDP socket when sending data to incorrect destination.
Test program:
asyncio output:
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/root/.pyenv/versions/3.8.2/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
return future.result()
File "", line 14, in main
File "/root/.pyenv/versions/3.8.2/lib/python3.8/asyncio/selector_events.py", line 1056, in sendto
self._fatal_error(
File "/root/.pyenv/versions/3.8.2/lib/python3.8/asyncio/selector_events.py", line 703, in _fatal_error
self._loop.call_exception_handler({
AttributeError: 'NoneType' object has no attribute 'call_exception_handler'
uvloop output:
Then we can cut off first block with sending to None destination. And here we have NEW ONE differece in handling ip:port.
When i run it with asyncio event loop all looks fine, socket still present.
When i run it with uvloop it silently closes, and also i can go into infinity wait on
recv()callAs i know RFC describe that case as (https://tools.ietf.org/html/rfc8085#section-5.1):
But i got real messages from the internet with that port. I will drop it in my application, but i think uvloop should not silently closes socket. It's very unexpected and differ from asyncio event loop.
Proof from Sentry (https://github.com/spumer/source-query-proxy):
next iteration of recv packet was failed, cause in previous we send response to zero port
