Re: [Gc] Problem with GC on FreeBSD
ivmai at mail.ru
Sun Apr 22 06:07:52 PDT 2012
Hi Petter, Vitaly and Hans,
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.
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).
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.)
Fri, 20 Apr 2012 10:23:24 +0200 Petter Urkedal <urkedal at nbi.dk>:
> Hi Ivan,
> I pushed a suggestion for a fix to
> 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.
> 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
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc