RuntimeError: File descriptor 2877 is used by transport <TCPTransport closed=False reading=True 0x55b8dc9baa90> #653

Activity

1. top-oai commented on Feb 14, 2025

   

   top-oai

   on Feb 14, 2025

   More actions

   I have also encountered this issue when upgrading from aiohttp 3.9.5 -> 3.11.11.

   I was able to reproduce with this test script (gist) on Ubuntu 24 x86.

   After some experimentation I found that aio-libs/aiohttp#10464 resolved the issue for my test script... however it does feel like there's something funny on uvloop's side here, in that when an exception is thrown on this line:

   uvloop/uvloop/loop.pyx

   Line 2066 in 7bb12a1

   await waiter

   then it is possible for the transport to linger on in

   uvloop/uvloop/loop.pyx

   Line 150 in 7bb12a1

   self._transports = weakref_WeakValueDictionary()

   despite the file descriptor being relinquished to the OS.
2. top-oai commented on Feb 16, 2025

   

   top-oai

   on Feb 16, 2025

   More actions

   Also, it looks like #646 would be a uvloop-side fix for this issue.
3. azisso commented on Oct 28, 2026

   

   azisso

   on Oct 28, 2026

   More actions

   We hit this in production (uvicorn + aiohttp client, uvloop 0.22.1, aiohttp 3.14.5, aiohappyeyeballs 2.6.1, Python 3.11) and can confirm it is the create_connection(sock=...) cancellation double-close described in #738, which #740 fixed in 0.23.0.

   Mechanism we confirmed: aiohttp connects the socket via aiohappyeyeballs, then calls loop.create_connection(sock=sock). If the task is cancelled while parked on await waiter (any wait_for / client timeout landing in that window), 0.22.1 calls tr._close() before _attach_fileobj(sock), so libuv closes the fd but the Python socket keeps the fd number. The OS reuses the number for a new connection, the stale socket is garbage-collected and closes it again, and from then on every new socket that gets that number fails with File descriptor N is used by transport <TCPTransport closed=False reading=True ...>. A blocked event loop makes the window much easier to hit.

   Minimal repro:

   import asyncio, socket, gc, uvloop
   
   class P(asyncio.Protocol): pass
   
   async def main():
       loop = asyncio.get_running_loop()
       srv = await loop.create_server(P, "127.0.0.1", 0)
       port = srv.sockets[0].getsockname()[1]
       sock = socket.socket(); sock.setblocking(False)
       await loop.sock_connect(sock, ("127.0.0.1", port))
       t = loop.create_task(loop.create_connection(P, sock=sock))
       await asyncio.sleep(0)   # transport opened, task parked on `await waiter`
       t.cancel()
       try: await t
       except asyncio.CancelledError: pass
       print("stale sock fd:", sock.fileno())          # 0.22.1: still a number; 0.23.0: -1
       tr2, _ = await loop.create_connection(P, "127.0.0.1", port)  # reuses the fd number
       del t, sock; gc.collect()                       # stale socket closes tr2's fd
       s3 = socket.socket(); s3.setblocking(False)
       await loop.sock_connect(s3, ("127.0.0.1", port))  # 0.22.1: RuntimeError ... is used by transport
   
   uvloop.run(main())

   Results (same machine, same aiohttp/aiohappyeyeballs; a stress script with many aiohttp requests under short wait_for timeouts while the loop is periodically blocked):

   uvloop	minimal repro	stress run
   0.22.1	RuntimeError: File descriptor 12 is used by transport ...	5-7 errors within seconds
   0.23.0	socket detached, no error	0 errors in ~190k requests (2 runs)
   stock asyncio loop	n/a	0 errors in ~135k requests (2 runs)

   So for anyone landing here: upgrading to uvloop >= 0.23.0 resolves the cancellation path, and this issue can probably be closed as a duplicate of #738. Note that #785 describes a second, still-open path to the same double-close (connection reset before the TLS handshake, Linux only), which 0.23.0 does not cover.

   (Investigation and repro done with AI assistance; the outputs above are from actual runs.)