[Gc] a bug in v.7.1 ?

Glauco Masotti glauco.masotti at libero.it
Wed Mar 2 12:40:58 PST 2011


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.
> 




More information about the Gc mailing list