[Gc] Incremental collection/thread local free lists problem

Stewart Greenhill sgreenhill@iprimus.com.au
Tue, 13 May 2003 13:51:53 +0800


Hi Brian,

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 
assembley.
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 
applications.

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.

Cheers,
   Stewart

On Tuesday, May 13, 2003, at 12:45  PM, Brian Alliet wrote:

> Hi-
>
> 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?
>
> Thanks,
>
> -Brian
>
> _______________________________________________
> Gc mailing list
> Gc@linux.hpl.hp.com
> http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc
>