[Gc] a bug in v.7.1 ?

Glauco Masotti glauco.masotti at libero.it
Sun Mar 6 10:18:44 PST 2011

I am at it.
As suggested by Hans, I stepped to the last version.
The problem is still there, so the chances that it's a bug in my code are high.
In order to find it I need to resort also to the debugging facilities of the collector. But... I don't get anything in 
the log file!?
I remember that with older versions (e.g. 6.2, 6.6) it was easy to get a very verbose gc.log file.
With 7.1, and 7.2 the default log file is <name of the executable>.log, right? But there is nothing in it, a part what I 
explicitly wrote there with GC_WARNING (!?).
I defined GC_DEBUG before gc.h, and GC_QUIET=0.
In the documentation there is apparently nothing new regarding this issues.
What did I do wrong or forgot to do?
Sorry to bother you, but perhaps I am getting too old for this tasks :-( and a simple hint from you could save me a lot 
of time.
--- GM

----- 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 
> 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
>> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list