[MLton] Shared libraries for MLton
Tue, 26 Jul 2005 12:37:32 -0400 (EDT)
> > >> o NOTE: The first garbage collection provokes a crash, the
> > >> error is probably to be found here.
> > >
> > > That is unfortunate.
> > Indeed. Fixing it requires a bit more knowledge of the inner
> > workings of MLton than I have at the moment, so I hope someone
> > can point in the right direction.
> As best I can make out, the problem is that the Thread_returnToC primitive
> does not leave the ML stack in a good state. Apparently, we don't do as
> many assertions and don't make as many assumptions about the
> callFromCHandler thread as we do about the currentThread. And, whatever
> bad state the callFromCHandler thread is in, it is fixed when transfering
> control to an _export-ed ML function before a GC occurs when the
> callFromCHandler thread as been switched to.
Interestingly enough, if I add
GC_switchToThread (&gcState, gcState.callFromCHandler, 0); \
to the end of init_function in c-main.h, then I can get Jens' example to
compile and run without any segfault. As a bonus, this also works for the
bytecode codegen, though the native x86 codegen has a mysterious segfault
when trying to return to init_function.
However, I note that compiling the shared library with -debug true,
thereby linking with a runtime with more assertion checks, then there is
an assertion failure:
gc.c:480: assert(0 <= index and index < s->frameLayoutsSize) failed.
which points to a stack in a bad state.
As to why returnToC from the main thread leaves the stack in a bad
(segfaulting) state, but returnToC from an _export-ed function leaves the
callFromCHandler stack in a good enough state to make another C-call to an
_exported function, I don't know.
I note that the C and bytecode codegens treat Thread_returnToC as
primitives, while the x86 codegen treats it a a C-call. The interesting
thing about the x86 codegen is that because Thread_returnToC is treated as
a C-call (translated in ssa-to-rssa.fun), then the resulting C-call is
marked as a runtime call, so the appropriate frame markers are inserted.
On the other hand, the C and bytecode codegens don't do anything special
to mark the stack at the point of a Thread_returnToC primitive.