This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: memory handling in qsort
- To: <glibc-linux at ricardo dot ecn dot wfu dot edu>
- Subject: Re: memory handling in qsort
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Mon, 5 Mar 2001 11:08:33 -0800 (PST)
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On Mon, 5 Mar 2001, Allin Cottrell wrote:
> Date: Mon, 5 Mar 2001 11:45:21 -0500 (EST)
> From: Allin Cottrell <cottrell@wfu.edu>
> Reply-To: glibc-linux@ricardo.ecn.wfu.edu
> To: glibc-linux@ricardo.ecn.wfu.edu
> Subject: memory handling in qsort
>
> I'm wondering if I might have found a small memory leak in qsort, in
> glibc 2.2.1.
>
> I'm memory-checking an application of mine, and when a large data set
> is given to qsort I'm seeing a 6-byte leak.
Relax, it looks like it's just allocating some global ``singleton''
object underneath sysconf. Some parts of libc do this in order to avoid
reserving static storage upfront.
A memory leak occurs when a piece of dynamic memory becomes unreachable
(the program loses its last pointer to it). How do you know this is
the case here?
Yamd, and other debuggers, usually can't distinguish between memory
that is allocated but never released and a true memory leak. Memory in
the former category can only be *suspected* to be a leak.