Re: GC Errors in Embedded Program

[Brent Fulgham <bfulgham@debian.org>]

On Wed, Dec 27, 2000 at 08:47:09AM -0800, Matthew Flatt wrote:
> MzScheme does not like to be called from a thread that is not the one
> used to call scheme_basic_env(), and not an OS-level thread that
> MzScheme itself creates. In the trace above, it looks like MzScheme was
> called from a new thread created by the embedding program.
> 
> I think the particular crash you're seeing is because the GC is
> prepared to work on the C stack from the thread that called
> scheme_basic_env(), and it gets confused because the stack has moved.
> 
> The usual solution to this problem is to create a server (OS-level)
> thread for evaluating MzScheme expressions. The server thread might
> spawn MzScheme threads to handle requests.
> 

Unfortunately, the problems don't seem to be resolved that easily.

I reworked the code to use an MzScheme server (wrapped in a little
C++ class) that would wait for requests from the client part of
the program.  It would pass these requests on to MzScheme for the
real work.

The first part of the constructor for this class is to create a new
OS-level thread, which in turn calls "scheme_basic_env()" and is
then supposed to loop forever checking an input queue of evaluation
requests.

Here's what I actually get:

[27/Dec/2000:23:52:34][2089.1024][-main-] Notice: modload: loading '/usr/lib/aolserver/bin/nsmachv.so'
[27/Dec/2000:23:52:34][2089.1024][-main-] Notice: MachV: EnableMV set to on.
[27/Dec/2000:23:52:34][2089.1024][-main-] Notice: Machiavelli is starting.
[27/Dec/2000:23:52:34][2089.1024][-main-] Debug: MachV: Constructing MV_InterpreterPool.
[New Thread 4101 (LWP 2096)]
[27/Dec/2000:23:52:34][2089.4101][MachV Intrp Svr] Notice: MachV:  Setting basic environment.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4101 (LWP 2096)]
GC_push_all_eager (bottom=0xbf1ff8a8 "Èø\037¿áJ6@¨ø\037¿", 
    top=0xc0000000 <Address 0xc0000000 out of bounds>) at ./mark.c:854
854     ./mark.c: No such file or directory.
(gdb) bt
#0  _push_all_eager (bottom=0xbf1ff8a8 "Èø\037¿áJ6@¨ø\037¿", 
    top=0xc0000000 <Address 0xc0000000 out of bounds>) at ./mark.c:854
#1  0x40365d0c in GC_push_all_stack_partially_eager (
    bottom=0xbf1ff8a8 "Èø\037¿áJ6@¨ø\037¿", 
    top=0xc0000000 <Address 0xc0000000 out of bounds>, 
    cold_gc_frame=0xbf1ff954 "") at ./mark.c:891
#2  0x40364ae1 in GC_push_current_stack (cold_gc_frame=0xbf1ff954 "")
    at ./mark_rts.c:430
#3  0x40364b3f in GC_push_roots (all=1, cold_gc_frame=0xbf1ff954 "")
    at ./mark_rts.c:487
#4  0x40365359 in GC_mark_some (cold_gc_frame=0xbf1ff954 "") at ./mark.c:309
#5  0x40361afa in GC_stopped_mark (stop_func=0x403616e0 <GC_never_stop_func>)
    at ./alloc.c:443
#6  0x40361983 in GC_try_to_collect_inner (
    stop_func=0x403616e0 <GC_never_stop_func>) at ./alloc.c:317
#7  0x40363bbc in GC_init_inner () at ./misc.c:557
#8  0x40367a77 in GC_generic_malloc_inner (lb=4, k=0) at ./malloc.c:61
#9  0x40367b99 in GC_generic_malloc (lb=4, k=0) at ./malloc.c:129
#10 0x40367bfe in GC_malloc_atomic (lb=4) at ./malloc.c:175
#11 0x4034ffb8 in scheme_init_setjumpup () at ./setjmpup.c:149
#12 0x40319f4f in scheme_basic_env () at ./env.c:199
#13 0x403196d4 in Run (arg=0x8193d88) at ns_interps.cc:161
#14 0x81190bb in NsThreadMain (arg=0x81a45f0) at thread.c:241

===========================================================

Above you mention that:
> MzScheme does not like to be called from a thread that is not the one
> used to call scheme_basic_env(), and not an OS-level thread that
> MzScheme itself creates. In the trace above, it looks like MzScheme was
> called from a new thread created by the embedding program.

I'm not sure what you mean by "...and not an OS-level thread that
MzScheme itself creates."

This sounds like MzScheme should be forking the thread that will
satisfy the request.  Is that right?  If so, I may need to do
some additional thinking about how this works.

I think the problem may be that scheme_basic_env is not called
by the "main" thread of execution that launches the program
itself.  Looking back at the earlier stack dump, it looks like
MzScheme is really only happy if it get's called by the main
thread created by the OS when the program starts.  (You may recall
that the earlier dump showed scheme_basic_env returning successfully,
but future calls to scheme_eval and friends crashed because they
were coming from POSIX threads created later on in the program run.)
Any threads created by the program through calls to POSIX functions,
etc., seem to be unsatisfactory for some reason.

Has anyone else seen this behavior?  What's different about the
"-main-" thread versus a thread created later on?

Could this problem be resolved using the SGC collector instead?

Thanks,

-Brent