Re[2]: [Gc] Problem with GC on FreeBSD

[Ivan Maidanski]

Hi Petter, Vitaly and Hans,

Vitaly -
1. Please test branch 'fix-freelist-check-and-specific' (it should only fix the problem for --enable-gc-assertions)
2. I'm still puzzled what's the problem USE_CUSTOM_SPECIFIC (which is defined by default for FreeBSD for now unless you set USE_PTHREAD_SPECIFIC) - looks like some thread is not unregistered (i.e. GC_remove_specific not called) on exit.

Petter -
I'm not sure about the the correctness of the fix proposed by your. So, I put it into another branch for a while - https://github.com/ivmai/bdwgc/tree/fix-freelist-check-and-specific
I've split your patch into a refactoring one and the fix itself (with minor modifications like 2nd AO_load_acq -> AO_load).

The alternate solution could be to call the check with the stopped world (but it seems to me not a trivial task to move the check there).

Hans -
1. Could you express your opinion about the proposed fix - https://github.com/ivmai/bdwgc/commit/c3dae88f9cc38c75d8450c0946fe9c4206cfd592
2. Should GC be disabled in GC_setspecific for tse allocation? - https://github.com/ivmai/bdwgc/commit/b71fcac4d1b65e2f412cf7edd3a6979aeb870a33
(I can't make it crash with implicit GC_gcollect_inner but I'm not sure whether GC there is always harmless.)

Regards.

Fri, 20 Apr 2012 10:23:24 +0200 Petter Urkedal <urkedal at nbi.dk>:
> Hi Ivan,
> 
> I pushed a suggestion for a fix to
> https://github.com/paurkedal/bdwgc/compare/fix-freelist-checks
> While traversing the free-list, it it re-reads the pointer to the
> current node before accepting its next-pointer, and bails out if it has
> changed.  That way, it won't try to follow a pointer which may be been
> modified after the object was returned to the client.  It may perform
> the mark-check on a just allocated object, but that should be harmless.
> The solution is a bit unorthodox, so you may want to have a good look.
> 
> Petter
> 
> On 2012-04-19, Petter Urkedal wrote:
> > I think I found the bug which makes disclaim_test fail.  The bug is also
> > reproducible using the regular GC_malloc if the library is compiled with
> > threads and --enable-gc-assertions, and the line
> > 
> >     GC_ASSERT(GC_is_thread_tsd_valid(tsd));
> > 
> > is commented out from thread_local_alloc.c.  I attach a brewed down
> > version on disclaim_test.c which uses GC_malloc along with the change to
> > thread_local_alloc.c needed to unveil the bug.  I tried git-bisect to
> > located the offending commit, but this seems to go as far back as I was
> > able to compile, which includes 3c50a689ca85f4fe56afbc8da9e894c4cc3af845
> > (gc7.0alpha5 tarball import).
> > 
> > The issue is that GC_check_tls goes though the thread-local structures
> > of other threads.  So, it seems GC_check_tls picks up an object from the
> > free list which is just about to be unlinked and returned to the caller
> > by another thread.  Therefore the issue is only seen when assertions are
> > enabled.  On the other hand the locking done by
> > GC_is_thread_tsd_valid(tsd) seems sufficient to hide the issue, even
> > though it does not surround the actual unlinking of the free list.  This
> > can be verified by replacing the "GC_is_thread_tsd_valid(tsd)" call with
> > "LOCK(); UNLOCK();"
> > 
> > Ivan, Hans: Any suggestion what's the best way to fix this?
> > _______________________________________________
> > 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/
>