[Gc] Incremental collection/thread local free lists problem
Tue, 13 May 2003 13:51:53 +0800
We've been using the GC for a long time now within the OOC project
(ooc.sourceforge.net). I must say that I'm surprised at how reliable it
seems to be. However, recently I've been working under Mac OS X and
have had all kinds of problems, which I'll try to summarise here.
OOC is an optimising compiler for the Oberon-2 language. It does a lot
of data-structure manipulations:
1) Builds an abstract syntax tree (AST) from source code.
2) Builds an intermediate representation (IR) from the AST.
3) Translates the AST to single-static assignment form (SSA).
4) Optimises the SSA form and finally emits code in C, or ia32
OOC can build static executables, or dynamically-linked executables in
which separate packages are in separate library files.
Under OS 10.1.5, I there was a particular version of the GC that seemed
to work for statically linked applications (GC 6.0, I think). After I
upgraded to OS 10.2, that stopped working. The 10.2 developer tools
shipped with libtool, so I started to try building dynamically linked
applications. GC 6.2alpha3 seems to work for statically linked
applications, but fails rather badly for dynamically linked
I've tried 6.2alpha3-darwin-test2, and that seems to solve some of the
library problems, but it crashes the compiler itself. I get a "type
guard failed" error while compiling itself. I interpret this as
indicating that an object has been corrupted or reclaimed that is still
referenced. If I understand what you're saying, this may be a symptom
of the same problem that you have found.
Sorry I can't offer a solution, but I do have a repeatable way of
reproducing the problem.
I would love to know what's going on here, and why OS X seems to be a
source of so many difficulties.
On Tuesday, May 13, 2003, at 12:45 PM, 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