[Gc] a bug in v.7.1 ?
bruce at hoult.org
Wed Mar 2 01:17:58 PST 2011
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