[MLton] Re: MLton and shared libraries

[Stephen Weeks]

> Program received signal SIGSEGV, Segmentation fault.
> Chunk0 () at test.1.c:5084
> 5084            S(Word32, 0) = 0;
...
> Since S is defined as
> 
> #define S(ty, i) *(ty*)(StackTop + (i))
> 
> in c-chunk.h, this is merely a write to the first element
> of the stack. Which shouldn't be able to fail unless the
> GC hasn't been initialized - I think.

That seems right to me.

> Apropos, should gcState.isOriginal be true after a call
> to GC_init ?

Yes, unless the command line has "@MLton load-world ...".

> Anyways, Chunk 0 is the only chunk in test.1.c and the
> offending line is in the very end:
...
> L_1:
>          S(Word32, 0) = 0;          ;;; <- HERE
>          Push (4);
>          FlushFrontier();
>          FlushStackTop();
>          GC_gc (GCState, 0x45C, 0x0, __FILE__, __LINE__);
>          CacheFrontier();
>          CacheStackTop();
> L_0:
>          Push (-4);
>          goto L_4;
...
> case 0:
>          goto L_0;

This looks like the first call to the GC in the program, which is to
make space to allocate the globals (presumably there is a limit check
that fails and jumps to L_1).  The "S(Word32, 0) = 0" stores the
return address (0) on the stack.  The return address (0) is handled 
by the "case 0:", which will jump to the right return code (L_0),
although in this case, the program isn't multithreaded, so MLton knows
to generate code to fall through to the L_0 block without ever
checking the return address.

Here are some suggestions.

 * step through GC_init and make sure it's actually running and that
   the stack is allocated.
 * recompile the runtime with various debugging options
   (DEBUG_DETAILED, DEBUG_STACKS, ...).
 * step through the MLton-generated C code starting as soon as Chunk0
   is entered and verify that the stack looks good.