Re: GC Errors in Embedded Program

[Brent Fulgham <bfulgham@debian.org>]

On Fri, Dec 29, 2000 at 05:44:10AM -0800, Matthew Flatt wrote:
> With the GC upgrade (version 103.4), I see that the stack-base routine
> changed for x86 Linux. Now it will always find the base of the main
> thread's stack.
> 

I'm pulling the CVS archive now to see if a libmzscheme/libgc with
the new code will work better.

> If the Boehm GC supports threads for your platform, then you might be
> able to fix the problem by turning on an appropriate compilation flag.
> (For Linux, it's either -DLINUX_THREADS or -DGC_LINUX_THREADS,
> depending on which version of the GC you have.)
> 

Unfortunately, the version in 103 makes some bad assumptions about
the pthreads implementation under Linux 2.2-series (Current GLIBC)
that cause it to fail.

I foolishly copied Boehm's current stable collector in its place,
and while it compiles fine the rest of MzScheme now won't compile.
I think there might have been some changes to the Boehm interface
in your version.

> > Could this problem be resolved using the SGC collector instead?
> 
> Yes --- provided that you can get SGC to work. 
> 

This didn't seem to work.

> The reason SGC might work is that it expects some cooperation from the
> allocating program:
> 
>  * The allocating program must tell SGC where the stack starts by
>    calling GC_set_stack_base(). See plt/src/mzscheme/main.c for an
>    example call.
> 

Done.  Unfortunately, I am now segfaulting when the threaded code
attempts to lock a mutex.  I think there may still be some threading
issues in the SGC code base, even with Linux Threads.

Oh well.  Isn't all this testing fun?  ;-)

-Brent