[PATCH] Re: Found? Re: [Gc] Assertion failure in GC_malloc_uncollectabl

Boehm, Hans hans.boehm at hp.com
Wed May 16 16:33:28 PDT 2012


Our current version numbering unfortunately doesn't really handle this case.  Historically we've just produced another stable version with the fix eventually, which isn't a good solution here.  It makes sense to switch to a version numbering scheme that handles small bug fixes like this better.  Unfortunately the obvious alternatives seem to cause the GC_version variable to behave strangely, so that "newer" no longer corresponds to ">".  Maybe we just need to introduce a revision number which isn't reflected in GC_version for now and switch to a different scheme when we would otherwise bump the version to 7.4.

Hans

> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru]
> Sent: Wednesday, May 16, 2012 2:39 AM
> To: Boehm, Hans
> Cc: Jan Wielemaker; gc at linux.hpl.hp.com
> Subject: Re[6]: [PATCH] Re: Found? Re: [Gc] Assertion failure in
> GC_malloc_uncollectabl
> 
> Hi Hans,
> 
> I've committed the fix (exactly the change as you said) to GC
> v7.3alpha3. (I think later (although I'm not sure right now) to replace
> GC_generic_malloc call with GC_generic_malloc_internal one in
> GC_malloc_uncollectable to avoid locking twice.)
> 
> But v7.2 should also be fixed - please consult me with the versioning:
> it should be something like v7.2.1 but not some alpha.
> 
> Regards.
> 
> Wed, 16 May 2012 05:47:08 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> > I'd be inclined just to make the offending assertion contingent on
> the absence of threads.  It seems to me that aside from the assertion,
> the code does the right thing, no matter what.  If a GC intervened,
> setting the mark bit to and setting n_marks to 1 (not incrementing)
> should do exactly the right thing.  We're holding a reference, which
> should be marked, and n_marks should be exactly one.
> GC_malloc_atomic_uncollectable() clearly does need the same treatment,
> as you pointed out.
> >
> > Jan's fix should also work, but cluttering GC_generic_malloc() with
> the details of UNCOLLECTABLE and AUNCOLLECTABLE seems less desirable to
> me.  Since these are large blocks, I think the small performance win in
> Jan's solution doesn't matter much.
> >
> > Hans
> >
> > > -----Original Message-----
> > > From: gc-bounces at linux.hpl.hp.com [mailto:gc-
> bounces at linux.hpl.hp.com]
> > > On Behalf Of Ivan Maidanski
> > > Sent: Tuesday, May 15, 2012 3:40 AM
> > > To: Jan Wielemaker
> > > Cc: gc at linux.hpl.hp.com
> > > Subject: Re[4]: [PATCH] Re: Found? Re: [Gc] Assertion failure in
> > > GC_malloc_uncollectabl
> > >
> > > Hi Jan,
> > >
> > > I'll spend more for this bug some days later and select the way to
> fix
> > > it.
> > >
> > > Regards.
> > >
> > > Tue, 15 May 2012 12:00:52 +0200 Jan Wielemaker
> <J.Wielemaker at vu.nl>:
> > > > On 05/15/2012 11:21 AM, Ivan Maidanski wrote:
> > > > >> My motivation to move this into GC_malloc_generic() was
> twofold:
> > > > >> clearly
> > > > >>> GC can come in between and it seems a waste to acquire the
> lock
> > > > >>> twice for a single operation with only a few unlocked
> > > > >>> instructions in between.
> > > >
> > > > > I understand. But, the other alternative is to use lock-less
> > > > > GC_generic_malloc_internal (not sure right now that its
> > > functionality
> > > > > is the same as GC_generic_malloc).
> > > >
> > > > I leave that decision to the experts.  I'm happy to test.
> > > >
> > > > > BTW. We should also fix GC_malloc_atomic_uncollectable.
> > > >
> > > > Looks like it is doing the same thing.
> > > >
> > > > Thanks for looking into this.  I still like to run with gc
> assertions
> > > > enabled as long as I'm developing.
> > > >
> > > > 		--- Jan
> > > >
> > > >
> > > > _______________________________________________
> > > > 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/
> >
> > _______________________________________________
> > 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