[Gc] Incremental collection/thread local free lists problem
Mon, 12 May 2003 22:37:38 -0700 (PDT)
That's probably a generic bug related to the combination of thread-local
allocation and incremental collection. I just uncovered and fixed it in my
My theory so far was that it was likely to occur only on slow
multiprocessors, or perhaps for large applications. Does your environment
fit that description? If not, there may be another issue.
If I make a 6.2alpha5 available tomorrow, how painful would it be for
you to switch to that? It would also make it easier for me to integrate
your patch, I suspect.
On Tue, 13 May 2003, Brian Alliet wrote:
> I was just about to put some finishing touches on my darwin patch a few
> weeks ago when I decided to take a stab at getting the incremental
> collector going on darwin. Unfortunately, it appears I ran into another
> bug in my darwin patch that only seems to show up when incremental
> collection is turned on. I know bug is not in my incremental collection
> code (getting the fault address, etc) because it shows up with
> DEFAULT_VDB too. There is a good chance it has nothing to do with
> incremental collection at all, thats just what is triggering it.
> Gctest ends up blowing up in GC_set_fl_marks because there is an
> invalid pointer on one of the ptrfree_freelists. I modified
> GC_local_malloc_atomic to set the first four bytes of each pointer
> returned to 0xdeadbeef, and modified test.c (in mktree, the ifdef
> THREAD_LOCAL_ALLOC block) to just allocate a chunk of memory then not
> touch it at all. Sure enough, 0xdeadbeef ends up on the freelist
> somehow. If I have test.c modify the memory (memset(result,'a',17))
> sometimes 0xdeadbeef will show up, other times 0x61616161 (aaaa) will.
> Anybody have any ideas on how this could happen or any suggestions on
> where I should look?
> Gc mailing list