This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Improving Memory Leak Detection


I was trying to regress a bug at work to make sure it was fixed.  The
comments in the bug were saying that valgrind was showing some memory
leaks.   Went through the reproduction steps and saw that the
particular leak mentioned in the bug was gone but that valgrind was
reporting more leaks.  After a discussion with the developer, I see
that these other mis-reported leaks are due to a common coding
practice.  The practice is to not worry about the cleanup of one-time
allocations or cleanups on 'exit' calls.  Im not sure I agree with the
practice because it generates noise for the memory profiling tools,
and to me seems a little lazy.  For early exits im not sure if there
is a good solution to eliminate the noise, but for one-time
allocations I believe there is.

The solution to me is in the language and base libraries.  Valgrind is
tracing calls to specific memory allocation functions if I am not
mistaken.  I believe a good solution to eliminate some of this type of
one time allocation noise is to use a special function for one-time
allocations to variables and enforce that in the language.  For C++, a
type modifier similar to 'const' that would indicate to the compiler
that the one-time allocation function should be used to create the
object.

For C style mallocs or calls to 'malloc' the compiler could enforce
the use of the specific malloc function with the modifier to help
eliminate memory leak noise.

Myron


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]