The AsyncFd in Tokio has a serious memory leak issue.

[silence-coding]

I'm not sure if the issue is with my usage, and I look forward to your help. Here is my reproduction code.
main.rs

use std::sync::Arc;
use std::time::Duration;
use tokio::io::unix::AsyncFd;

#[tokio::main]
async fn main() {
    loop {
        let fd = unsafe { libc::inotify_init1(libc::O_CLOEXEC | libc::O_NONBLOCK) };
        if fd == -1 {
            return;
        }
        let afd = Arc::new(fd);
        let async_fd = AsyncFd::new(afd.clone()).unwrap();
        unsafe {
            libc::close(fd);
        }
        tokio::time::sleep(Duration::from_millis(1)).await;
        drop(async_fd);
    }
}

Cargo.toml

[dependencies]
[package]
name = "testexamples"
version = "0.1.0"
edition = "2024"

[dependencies]
tokio = { version = "1.47.1", features = ["full"] }
libc = "0.2.174"

[ADD-SP]

I think closing the fd before dropping the AsyncFd breaks the contract mentioned in the docs.

The AsyncFd takes ownership of an arbitrary object to represent the IO object.

https://docs.rs/tokio/1.47.1/tokio/io/unix/struct.AsyncFd.html

Since the AsyncFd owns the fd, the caller shouldn't close it before taking the ownership back.

---

tokio/tokio/src/runtime/io/driver.rs

Lines 263 to 281 in 925c614

	pub(super) fn deregister_source(
	&self,
	registration: &Arc<ScheduledIo>,
	source: &mut impl Source,
	) -> io::Result<()> {
	// Deregister the source with the OS poller **first**
	self.registry.deregister(source)?;
	if self
	.registrations
	.deregister(&mut self.synced.lock(), registration)
	{
	self.unpark();
	}
	self.metrics.dec_fd_count();
	Ok(())
	}

The leakage is caused by because L269 returns an error and interrupts the cleanup logic, leading to resource leakage in the intrusive list. I believe there is no leakage if you drop(async_fd) before the libc::close() or async_fd.into_inner() before the libc:cllose().

I believe we should avoid cleaning up the intrusive list if L269 fails, since L269 is not expected to fail. If it does, it’s likely an indication of an exceptional or rare failure scenario—either incorrect usage or a bug in Tokio.

However, unconditionally cleaning the intrusive list could break the memory safety. Given that L269 failure is a rare and extreme case, it becomes even more crucial to prioritize memory safety in such situations, rather than focusing solely on preventing memory leaks.

[Darksonn]

Removing it from the instrusive list doesn't necessarily break memory safety. If we can, I think we should.

[ADD-SP]

My gut tells me that this issue involves several classic engineering topic:

• “Let it crash" vs. "Keep it running" vs. "Best effort"
• "Unrecoverable error" vs. "Recoverable error"

We may need to do granular error handling in this scenario, for example, it might be acceptable to cleanup up the intrusive list on ENOENT, and we might want to simply panic on ELOOP, shortcut to epoll_ctl(2). And it might highly depend on the platform, we may don't have enough bandwidth.

I believe the coding itself isn't challenging, so my plan is to draft an RFC first, and then we can dive deeper into the discussion.

[Darksonn]

I don't think there are cases where we can't clean up the list on de register. ELOOP is only for registration.

[ADD-SP]

I don't think there are cases where we can't clean up the list on de register. ELOOP is only for registration.

You are right, now, I also think we can cleanup the list on de register as long as the error is properly propagated. Looks like there are two PRs we need.

1. Cleanup the list on de register.
2. Propagated the error out of the AsyncFd (panic? or Result?).

[silence-coding]

Thank you very much, everyone. I resolved my issue by following your suggestions. I look forward to seeing AsyncFd become more robust in the future.

[Darksonn]

Propagated the error out of the AsyncFd (panic? or Result?).

I believe this operations happens on AsyncFd drop. I don't think we can propagate the error at all in that scenario. Similar to std::fs::File, we probably just have to swallow the error.

[ADD-SP]

Propagated the error out of the AsyncFd (panic? or Result?).

I believe this operations happens on AsyncFd drop. I don't think we can propagate the error at all in that scenario. Similar to std::fs::File, we probably just have to swallow the error.

For AsyncFd::drop we cannot propagate the error, but this error can also happen on AsyncFd::into_inner(). We may need a new method like try_into_inner or just panic in the into_inner().

https://docs.rs/tokio/1.47.1/tokio/io/unix/struct.AsyncFd.html#method.into_inner