Are unclosed file descriptors a memory leak?

[oli-obk]

We do not check whether file descriptors got closed before exiting the program.

While it's not wrong per-se, the file descriptors will get closed by the kernel after the program finishes, the same is true for leaked allocations.

Should we report them the same way we report memory leaks? Obviously not for stdin, stdout, and stderr, but for everything else...

[RalfJung]

The flipside is that we have to be careful to not report deliberate leaks. One of the unfortunate side-effects of people getting leak reports from valgrind is that people "fixed" their code by having C++ static variables be freed during program exit which now causes race conditions when one thread calls exit while another thread works on that static... if something truly lives for the entire duration of the program, just leaking it is the best option, better than freeing it at exit.

For memory, we have a bunch of machinery to handle this as good as we can: memory reachable via statics and even main-thread thread-locals is not considered leaking. For file descriptors it seems to be hard to do anything like that, so I am not sure how to best handle this.

[oli-obk]

Right. and especially for something like loggers, which live globally, but may have handles to files or even the network, handling that is just going to be a pain. I guess wontfix, but could possibly add an opt-in flag for checking file descriptors just like valgrind has: --track-fds=yes

[RalfJung]

In that case we'd probably at least want a function like miri_leak_fd to mark an FD as deliberately leaked.