[unixODBC-support] Memory leak in SQLFetch?

Eric Sharkey sharkey at netrics.com
Tue Dec 14 19:59:52 GMT 2004

> If I understand it correctly, the system memory usage on Linux sometimes
> includes memory that the OS holds onto even after a program free's it so
> that it is in a cache ready to hand back to a program upon subsequent alloc
> calls.   

Not quite.  "Linux" does no such thing.  "Gnu/Linux" does.

In other words, the behavior you describe is part of glibc, which
provides the implementation of malloc() and free() most commonly used
on Linux systems.

This is actually tunable, using the macro M_TRIM_THRESHOLD which is
defined in malloc.c inside of the glibc source.  I believe the default
is to never give anything back to the OS at all.

> Watching the specific memory usage of a process is the more accurate method
> to use to detect memory leaks since this cached memory is not charged to the
> process in these counters.  The data for these tools (ps, top, gtop,) comes
> from the /proc filesystem which is in memory (like a ram-disk) and it keeps
> counters for each process running.

This isn't true.  The kernel and any process tables it maintains isn't
able to distinguish between memory held by a process which is actually
being used, and memory held by libc.

For more information, I recommend reading malloc.c in the gnu libc
source.  It's well commented.  I'm sure it will tell you much more
than you care to know.


More information about the unixODBC-support mailing list