Hello
We have an issue with our application, it randomly hangs and doesn't respond to new requests, at first we thought the problem lies within our code but after attaching to hanged process using gdb I couldn't find any code related to our application so I thought it might be python bug.
Here is the info extracted from gdb:
https://gist.github.com/k1-hedayati/96e28bf590c4392840650902cb5eceda
Python 3.5.2

We run multiple instances of our application and they are fine for a couple of days/hours but suddenly one of them starts hanging and others follow and unfortunately we can't reproduce the problem.
I'll be glad to receive any advice on how to solve or debug this issue.

I see no hang in attached snapshot but notmal behavior.

asyncio iterates over epoll.poll constantly waiting for network events or timeout.

Closing the issue.

I recently had a similar issue, a MWE can be found here (and also attached):
https://gist.github.com/N-Coder/89b1be8e5cfb83b1b03ade8485676982
As soon as `loop.stop` in loop_stop_problem.py:44 is called in a non-threadsafe way from another thread, i.e. without loop.call_soon_threadsafe, the loop seems to hang in `self._epoll.poll(timeout, max_ev)`.
This can be seen when comparing the two outputs in threadunsafe_loop_stop.log (without loop.call_soon_threadsafe) and call_soon_threadsafe_loop_stop.log (with loop.call_soon_threadsafe). Please note the time difference after "Waiting for loop join".
The loop seems to hang until the (seemingly random) epoll timeout occurs, or the next pending events needs to be processed (which might take quite some time).

There is also no explicit note about this behavior in the doc of the function (https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.stop), only a small note in the doc of AbstractEventLoop, informing you about the non-thread-safety of the whole class.
Also, other methods like `call_at` use `BaseEventLoop._check_thread` (https://github.com/python/cpython/blob/3.6/Lib/asyncio/base_events.py#L549) to check for violations when running in debug mode. Unfortunately, `stop` doesn't make those checks.
All this together makes this bug very hard to find.

So, i'd vote for adding a short `if self._debug: self._check_thread()` to the `stop` method.