io: always cleanup AsyncFd registration list on deregister

[F4RAN]

Fixes memory leak when fd is closed before AsyncFd drop.

Fixes: #7563

Motivation

When a file descriptor is closed before dropping AsyncFd, OS deregistration fails and causes an early return, preventing cleanup of the internal registration list. This leaks ScheduledIo objects over time.

Solution

Always clean up the internal registration list, even if OS deregistration fails. Store the OS result, perform cleanup, then return the error. This is safe because the list is Tokio's internal tracking - if OS deregister fails, the OS already doesn't track it, so cleanup doesn't break memory safety.

Includes a test reproducing the bug scenario.

[ADD-SP]

if OS deregister fails, the OS already doesn't track it, so cleanup doesn't break memory safety.

Could you please explain why? I'm curious on it.

[ADD-SP]

Only cleaning up the intrusive list may not be a proper fix of this issue. There are some questions we need to answer.

• Shall we propagate the error to the downstream user?
• When / When not propagate the error?
• How to propagate this error?
• Will our fix cause a breaking change?

[F4RAN]

Hi @ADD-SP,

Thanks for the feedback! I've updated the PR to address your questions.

Test Infrastructure Added

Added test-only methods to verify the fix:

• registration_set.rs: pending_release_count() and total_registration_count() (needed since LinkedList has no len())
• driver.rs: Wrapper methods
• handle.rs: Methods to expose counts for integration tests

All gated with #[cfg(feature = "full")] and #[doc(hidden)]. Kept /// TEST PURPOSE RELATED TO PR #7773 comments for easy removal later.

Test Evolution

Initial test only exercised the code path. Updated to check registration count after each iteration and assert it doesn't grow (indicating leak).

Platform-Specific Behavior

The leak cannot be reproduced on macOS. On Linux with epoll:

• With buggy code: Test fails, detecting 30 leaked ScheduledIo objects
• With fix: Test passes, count stays at baseline

The test is Linux-specific for leak detection but exercises the code path on macOS too.

Why Cleanup After OS Failure is Safe

if OS deregister fails, the OS already doesn't track it, so cleanup doesn't break memory safety.

Could you please explain why? I'm curious on it.

When mio::Registry::deregister() fails (typically EBADF for closed fds), the OS kernel already doesn't track this fd in its polling mechanism (epoll/kqueue). The ScheduledIo in Tokio's internal registrations list is just our bookkeeping - removing it doesn't affect the kernel or other resources. Since the OS doesn't know about the fd anymore, cleaning up our internal tracking is safe and doesn't break memory safety.

Remaining Questions

Only cleaning up the intrusive list may not be a proper fix of this issue. There are some questions we need to answer.

• Shall we propagate the error to the downstream user?
• When / When not propagate the error?
• How to propagate this error?
• Will our fix cause a breaking change?

Per your comment in #7563, I see two options for into_inner(): (1)add try_into_inner() (non-breaking) or (2) panic on error. I recommend Option 1 for non-breaking behavior and user choice, but I can implement Option 2 if you prefer.

1. Shall we propagate the error to the downstream user?
   Yes, but make it optional via try_into_inner() so users can choose.
2. When / When not propagate the error?
   Not in Drop (can't return errors), but yes in into_inner() via optional try_into_inner() while keeping into_inner() ignoring errors for compatibility.
3. How to propagate this error?
   Add try_into_inner() -> Result<T, (T, io::Error)> (Option 1).
4. Will our fix cause a breaking change?
   No.

Thanks again!

[F4RAN]

Can Miri or address sanitizer capture this memory leak?
Hi again @ADD-SP,
Thanks for your idea.

I'll be appreciated if you check my rss-based test:

Summary

I tested several approaches as suggested:

Approach	Result
LeakSanitizer	❌ Cannot detect - objects are still reachable via internal linked list (logical leak, not unreachable memory)
Miri	❌ Cannot run - requires system calls (epoll_ctl, libc::close, sockets)

Since this is a "logical leak" (objects stuck in a data structure, not truly unreachable), standard leak detectors don't work.

Solution: RSS-based memory test

I implemented a test that monitors RSS (Resident Set Size) before and after running 5000 iterations. No internal API access needed - just reads /proc/self/statm.

Linux results:

• Without fix: FAILED - RSS grew by 1920KB (leak detected!)
• With fix: PASSED - RSS stable

The test is gated with #[cfg(target_os = "linux")] since it reads /proc/self/statm.

[Darksonn]

Miri does support epoll.

[F4RAN]

Miri does support epoll.

Hi @Darksonn.
I tested with Miri on Linux. Both with and without the fix, Miri reports no leak:

test memory_leak_miri_check ... ok
Miri detects unreachable memory, but this is a logical leak - the ScheduledIo objects remain reachable through the internal registrations linked list. They're not orphaned allocations, they're just never removed when the fd is closed before drop. Same reason LSan couldn't detect it. The RSS-based test remains the practical way to verify this fix works - it detects unbounded memory growth across multiple phases.

[Darksonn]

Miri detects unreachable memory

Are you saying that miri detects it, and that miri doesn't detect it when the fix is applied? That sounds like a pretty good way to test it.

[F4RAN]

Miri detects unreachable memory

Are you saying that miri detects it, and that miri doesn't detect it when the fix is applied? That sounds like a pretty good way to test it.

To clarify: Miri cannot detect this leak - neither with nor without the fix. Miri is designed to detect unreachable memory (orphaned allocations). But this is a logical leak where objects remain reachable through the internal registrations linked list - they're just never removed. Since they're still reachable, Miri sees no problem. Same reason LSan couldn't detect it. The RSS-based test is the practical solution since it measures actual memory growth.

Both with and without the fix, Miri reports no leak

[Darksonn]

Relying on RSS is going to be extremely fragile. Your memory allocator may keep memory around even if the program has freed it, and this still counts in RSS.

If we're going the route of measuring memory, then please declare a #[global_allocator] that increments/decrements a static AtomicUsize for tracking the memory actually in use (it may forward calls into the system allocator to perform actual allocation), and use this to measure the amount instead.

The test needs to be moved to its own file so the #[global_allocator] does not affect other tests.

[F4RAN]

Relying on RSS is going to be extremely fragile. Your memory allocator may keep memory around even if the program has freed it, and this still counts in RSS.

If we're going the route of measuring memory, then please declare a #[global_allocator] that increments/decrements a static AtomicUsize for tracking the memory actually in use (it may forward calls into the system allocator to perform actual allocation), and use this to measure the amount instead.

The test needs to be moved to its own file so the #[global_allocator] does not affect other tests.

@Darksonn, Implemented a custom #[global_allocator] that tracks allocations via a static AtomicUsize, forwarding to the system allocator. The test is in io_async_fd_memory_leak.rs so the allocator only affects that file.
Verified on Linux: without the fix, the test fails with ~256KB growth per phase; with the fix, it passes with stable memory.

[Darksonn]

Thanks for adding the new test. One nit below.