[Gc] a bug in v.7.1 ?

Glauco Masotti glauco.masotti at libero.it
Sat Mar 5 01:17:42 PST 2011


Thanks Hans.
The memory mismanagements that I have found so far were not critical.  So the situation it's not clear. I will dig into 
this ASAP. Unfortunately these days I am taken also by other urgent tasks.
--- Glauco Masotti

----- Original Message ----- 
From: "Boehm, Hans" <hans.boehm at hp.com>
To: "Glauco Masotti" <glauco.masotti at libero.it>; "Bruce Hoult" <bruce at hoult.org>
Cc: <gc at linux.hpl.hp.com>
Sent: Friday, March 04, 2011 9:19 PM
Subject: RE: [Gc] a bug in v.7.1 ?


>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/
>
> _______________________________________________
> 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