Cancelling a task that's waiting on a closed socket -> TrioInternalError

[nonsleepr]

Using Python 3.7 on Mac with trio 0.4.0. A lot of noise on Ctrl+C:

^C
Traceback (most recent call last):
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 1229, in run
    result = run_impl(runner, async_fn, args)
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 1357, in run_impl
    runner.task_exited(task, final_result)
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 857, in task_exited
    task._parent_nursery._child_finished(task, result)
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 391, in _child_finished
    self._add_exc(result.error)
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 376, in _add_exc
    self.cancel_scope.cancel()
  File ".../lib/python3.7/site-packages/trio/_core/_ki.py", line 164, in wrapper
    return fn(*args, **kwargs)
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 149, in cancel
    task._attempt_delivery_of_any_pending_cancel()
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 558, in _attempt_delivery_of_any_pending_cancel
    self._attempt_abort(raise_cancel)
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 538, in _attempt_abort
    success = self._abort_func(raise_cancel)
  File ".../lib/python3.7/site-packages/trio/_core/_io_kqueue.py", line 106, in abort
    r = abort_func(raise_cancel)
  File ".../lib/python3.7/site-packages/trio/_core/_io_kqueue.py", line 122, in abort
    self._kqueue.control([event], 0)
FileNotFoundError: [Errno 2] No such file or directory

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../lib/python3.7/site-packages/trio/_core/_run.py", line 1235, in run
    ) from exc
trio.TrioInternalError: internal error in trio - please file a bug!

[njsmith]

Getting a traceback is normal – if you write a regular Python script that doesn't use trio and hit control-C, you'll get a traceback, and we try to match what regular Python does when it makes sense :-). (Sometimes trio's tracebacks are annoyingly wordy, which is something we want to fix, but that's not the issue here.)

What's strange here is the TrioInternalError. You should have gotten a KeyboardInterrupt and a traceback that shows your code, not a bunch of trio internals. It looks like you've hit some kind of bug inside the kqueue I/O manager's cancellation logic. We should figure that out and fix it.

[njsmith]

Ohhh, actually, I bet this is a side-effect of #341 – you have some task that's blocked waiting for an fd to become readable, and that fd got closed. Then cancel the waiting task, so trio tries to tell the kernel that it doesn't need to know about when the fd becomes readable after all, and the kernel is like "wtf are you talking about, there is no such fd" (because it was already closed).

Does that sound like it matches your script where you hit this issue?

If so, then the long-term solution is to fix #341, and the short-term workaround would be to make sure not to close a stream/socket/fd while there is still a task waiting on it. One way to accomplish this would be to make sure to cancel the task first before closing the stream, rather than afterwards.

[njsmith]

Okay, @nonsleepr confirmed in gitter that this was their code that caused the error, and that script does in fact block forever with a task waiting on a closed socket, so I think my diagnosis is correct.

[njsmith]

This was fixed by #460