[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unfreed memory within ls
From: |
Eric Blake |
Subject: |
Re: Unfreed memory within ls |
Date: |
Fri, 31 Aug 2007 15:38:37 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Mårten Wadenbäck <pi06mw9 <at> student.lth.se> writes:
>
> Greetings,
> I am using coreutils-6.9, and I have noticed that a few dynamically
> allocated variables in src/ls.c are never freed.
Thanks for the report. However, you seem to assume that this is a bug. All
proces memory is implicitly and efficiently freed by the OS at process exit,
and it only slows down execution to explicitly free all memory, not to mention
you have the potential for dirtying the cache or causing page faults, when the
process is about to exit. It is only a bug if memory is not freed when the
process intends to keep on running and allocate more memory, or when all
handles to allocated memory go out of scope without exiting. And your list of
variable names shows that we have not lost all handles to the allocated
memory. Yes, I agree that when doing a lint-like check, explicitly freeing
everything makes it easier to detect the presence of true memory leaks. But
dirtying and slowing the code in a non-lint scenario, just to free memory that
is allocated only once and whose handles are not lost, is not strictly
necessary; it is intentional that some of the coreutils skip freeing allocated
memory at exit.
--
Eric Blake