bug-coreutils
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]