[unixODBC-support] Memory leak in SQLFetch?

Saunders, Steve 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.
> 
> Eric
> _______________________________________________
> unixODBC-support mailing list
> unixODBC-support at easysoft.com
> http://mail.easysoft.com/mailman/listinfo/unixodbc-support
> 



More information about the unixODBC-support mailing list