[Gc] Problem with GC on FreeBSD
urkedal at nbi.dk
Fri Apr 20 01:23:24 PDT 2012
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
> 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
More information about the Gc