GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing github.com — `connect_read_pipe` double-closes the underlying fd, possibly closing an unrelated fd · Issue #763 · MagicStack/uvloop Open Labels DescriptionIn our production use of uvloop, we found sporadic cases of file descriptors being randomly closed. (For more details of our specific case, see skypilot-org/skypilot#10681). I used this script to check the double-close behavior: import asyncio, io, os, sys class BufferedReaderWithProbe(io.BufferedReader): def close(self): # Probe before status fd = self.fileno() print(f"closing {self} (fd {fd})") try: os.fstat(fd); fd_state = "still OPEN" except OSError as e: fd_state = f"already closed ({e.strerror})" # Open a new pipe to see what fds we get # Kernel should reuse lowest free number newfd_reader, newfd_writer = os.pipe() print(f" is fd {fd} already closed? {fd_state}") print(f" fresh os.pipe() got fds {newfd_reader},{newfd_writer}") # Do normal BufferedReader close try: print("calling BufferedReader.close") super().close() finally: # Probe after status print("Status after close:") for fd in (newfd_reader, newfd_writer): try: os.fstat(fd); print(f" fresh fd {fd}: alive") except OSError as e: print(f" fresh fd {fd}: DEAD ({e.strerror}) <-- stolen") async def main(): loop = asyncio.get_running_loop() pipe_read_fd, pipe_write_fd = os.pipe() probe_reader = BufferedReaderWithProbe(io.FileIO(pipe_read_fd, "rb")) transport, _ = await loop.connect_read_pipe(asyncio.Protocol, probe_reader) print(f"transport {type(transport).__name__} on fd {pipe_read_fd}") transport.close() if __name__ == "__main__": if sys.argv[1:] == ["uvloop"]: import uvloop; uvloop.install(); print(f"== uvloop {uvloop.__version__}") else: print(f"== stdlib asyncio {sys.version.split()[0]}") asyncio.run(main()) Here you can see that a asyncio event loop correctly leaves fd 6 open, allowing the underlying file object (in this case, our custom BufferedReader) to close the fd. This specific case was already fixed for sockets: d5195d7. It was assumed that the EBADF for non-sockets was benign, but it can actually be a problem if the underlying fd is reassigned before the You can observe the same behavior if the transport is not explicitly closed but is instead GC'd - although in this case it seems that the file object is closed before the It also looks like AI disclosure: This investigation was heavily assisted by AI tools, but this report was entirely human written without assistance except for the original repro script. The original repro script was then modified by me for clarity and manually validated. Reacted by Fantix King ActivityMetadataMetadataAssigneesLabelsTypeProjectsMilestoneRelationshipsDevelopmentIssue actions |
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |