[Gc] security issue with libgc ?

Hans Boehm Hans.Boehm at hp.com
Mon Mar 19 16:18:55 PST 2007

On Sun, 18 Mar 2007, skaller wrote:

> On Sat, 2007-03-17 at 22:22 +0100, Christophe Meessen wrote:
> > Thank you very much MentalGuy to take the time to answer. Now I start to
> > get the picture.
> Memory leak isn't the only problem: the gc only works if it can
> find ALL the accessible pointers. This means any encoding
> is suspicious .. for example an packed structure where a pointer
> is simply aligned incorrectly. It also means if you can't
> specify ALL the memory regions that might contain pointers,
> you're in trouble.
> For example if the system holds a pointer, or some library
> has a section of static store you don't know about,
> or, some library uses a private allocator, eg calls mmap
> directly.
The collector actually tries fairly hard to find some of these.  On
commonly used systems it does find data associated with libraries.
There are certain kinds of data which the collector cannot find, and
you do need to keep a copy of pointers in a more accessible place.
The most common instance of that is probably thread-local data, and
data in memory allocated by the systems malloc.  (The collector
does provide a replacement allocator for uncollectable memory that is

Pointers in mmapped files are also generally not traced, though that's
configurable on some common platforms.


More information about the Gc mailing list