[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GC Errors in Embedded Program



Quoting Brent Fulgham:
> A backtrace:
> 
> [...]
> #20 0x4031f4fa in scheme_eval_string (str=0x40366357 "(+ 1 2)", env=0x8334dc0)
>     at ./eval.c:3286
> #21 0x40310ac7 in MV_PageGet (ignored=0x0, conn=0x81dc670) at ns_machv.cc:489
> #22 0x8077d2a in Ns_ConnRunRequest (conn=0x81dc670) at op.c:196
> #23 0x807e5ee in ConnRun (connPtr=0x81dc670) at serv.c:810
> #24 0x807df1e in NsConnThread (arg=0x81f7af8) at serv.c:609
> #25 0x81190bb in NsThreadMain (arg=0x8254b80) at thread.c:241
> #26 0x4002ccb5 in pthread_start_thread () from /lib/libpthread.so.0
> #27 0x4002ccfd in pthread_start_thread_event () from /lib/libpthread.so.0
> 
> Is there any problem with multi-threaded programs embedding MzScheme?

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.

Matthew