[Gc] a bug in v.7.1 ?

Boehm, Hans hans.boehm at hp.com
Fri Mar 4 12:19:38 PST 2011


I would also recommend, on general principles, trying the CVS version.  There have been quite a few bug fixes since 7.1.

Hans

> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of Glauco Masotti
> Sent: Wednesday, March 02, 2011 12:41 PM
> To: Bruce Hoult
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] a bug in v.7.1 ?
> 
> Alright Bruce, thanks for your suggestions.
> I resumed some debug tools I developed some years ago for occasions
> like this, and they indicate that memory gets
> corrupted somewhere (some writing out of bounds, I think), so it's very
> much likely that also the collector gets fooled,
> sooner or later.
> It's very strange that no apparent malfunctioning showed up, before and
> apart this.
> The code is quite complex and I fear I must undergo a long and tedious
> debug session.
> Maybe I will resort also to the debug tools of the GC.
> I will keep you and the folks out there informed, if something relevant
> or instructive will come out from my labor.
> Take care.
> ---- Glauco Masotti
> 
> ----- Original Message -----
> From: "Bruce Hoult" <bruce at hoult.org>
> To: "Glauco Masotti" <glauco.masotti at libero.it>
> Cc: <gc at linux.hpl.hp.com>
> Sent: Wednesday, March 02, 2011 10:17 AM
> Subject: Re: [Gc] a bug in v.7.1 ?
> 
> 
> > On Wed, Mar 2, 2011 at 10:00 PM, Glauco Masotti
> > <glauco.masotti at libero.it> wrote:
> >> I would like it were so Bruce.
> >>
> >> I normally map free to no-op.
> >>
> >> There are only a few selected GC_FREE calls in the code, for some
> large
> >> arrays (allocated with malloc_atomic).
> >> This part of the code is there since several years, and super-
> tested, so I
> >> cannot believe it's the cause of this malfunction.
> >
> > OK, but have you actually tried it without them?
> >
> >
> >> In any case, if I placed some free in excess, this would compromise
> MMM as
> >> well, isn't it?
> >
> > Maybe, maybe not.
> >
> > Use-after-free bugs can be a problem in several ways.
> >
> > Most obviously if the memory manager has actually reused that memory
> > for something else but also the adding the block to a free list can
> > corrupt the first few bytes of the existing data. Many programs won't
> > actually access that data or will silently produce incorrect results
> > if they do. Modifying the first few bytes will also corrupt the NEXT
> > link which means that when the block is eventually used again the
> > pointer to the first free item of that size becomes junk.
> >
> > There are a number of things in the GC that can affect the timing of
> > when any particular block of memory might be allocated again. For
> > example for small objects the exact choice of sizes chosen to round
> up
> > allocations to. Or for large objects a setting such as
> > GC_use_entire_heap. I'm sure there are others too. The defaults or
> > heuristics can easily change between versions and have no effect on
> > correct code but result in buggy code causing problems at different
> > points in execution or even not at all.
> >
> 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list