Bug 278476
| Summary: | fd and memory leak in ls | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Paul Floyd <pjfloyd> |
| Component: | misc | Assignee: | Mark Johnston <markj> |
| Status: | In Progress --- | ||
| Severity: | Affects Only Me | CC: | markj, tamelingdaniel |
| Priority: | --- | ||
| Version: | 14.0-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Paul Floyd
2024-04-20 06:11:39 UTC
Is this report effectively just saying that ls doesn't close all of its fds before exiting? I don't think that's a bug: there's no point in calling close() when the kernel's going to clean up anyway. Does valgrind have any way of annotating code to suppress reports like that? There is a suppression mechanism but I can't put it the default suppression file as it would affect all other applications. It's not a serious problem. I use 'ls' and similar common userland applications (like sleep, false, id, pwd) for quick smoketests. About half of them don't free everything. If you do want something with annotation you can do something like
#include <valgrind.h>
...
if (RUNNING_ON_VALGRIND)
{
close(fd);
}
That adds a Valgrind dependency. It'd be a lot easier to just close the file descriptor.
The cause of the leak is that fts_open is called in the traverse function without a final fts_close: https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c#L636 After finishing the traverse function ls exits. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e6c9c463384d11a44af3e5f2cc947fb69f3a1968 commit e6c9c463384d11a44af3e5f2cc947fb69f3a1968 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2025-01-14 14:20:26 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2025-01-14 14:20:26 +0000 ls: Release resources before returning from traverse() PR: 278476 MFC after: 2 weeks Reported by: valgrind bin/ls/ls.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) |
