[Gc] Memory leak in multithreaded application

Bruce Hoult bruce at hoult.org
Tue May 15 17:32:56 PDT 2007

On 5/16/07, Christophe Meessen <meessen at cppm.in2p3.fr> wrote:
> Unfortunately I still see another step wise leak of 300KB. I saw it with
> gc6.8 too but only after the server was running for more than an hour.
> The client, single threaded, doesn't show this. Memory usage is all flat.
> With gc7.0a7 I saw it once after a few minute run. Appart from this,
> memory usage is flat and normal.

If it happens once then it's not a leak.  It's only a leak if it's
fairly steady with increasing run time (or increasing number of events
in an event-driven program).

Even with a steady processing load a memory increase can easily happen
as memory fragmentation builds up and, for example, a space where a
large object fitted on the first N iterations gets split up for
smaller objects and then a new place is required for the next large
object allocated.  This might be happening in malloc()'d data, or
new'd data, or it could even happen in GC data if you're allocating
objects larger than the GC block size (4 KB by default) in which case
the GC has to be able to find two (or more) free blocks that happen to
be next to each other.

Note that the STL, in particular, allocates memory in large chunks of
several hundred KB, and then uses that as a pool for all the hashmap
and linked list and vector and string objects in your program.  If
that gets fragmented (or just runs out) then STL will allocate another
large pool.

More information about the Gc mailing list