[unixODBC-support] Memory leak in SQLFetch?
ssaunders at docucorp.com
Tue Dec 14 20:07:01 GMT 2004
Thanks, like I said the guru know better.
> -----Original Message-----
> From: unixodbc-support-bounces at easysoft.com
> [mailto:unixodbc-support-bounces at easysoft.com]On Behalf Of
> Eric Sharkey
> Sent: Tuesday, December 14, 2004 3:00 PM
> To: Support for the unixODBC project
> Subject: Re: [unixODBC-support] Memory leak in SQLFetch?
> > 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.
> unixODBC-support mailing list
> unixODBC-support at easysoft.com
More information about the unixODBC-support