mltonlib opengl segfaults with mlton master

[ratmice]

I was trying out the opengl libraries in mltonlib/org/mlton/mike/opengl/unstable
but most executables segfault
under current master 22f61a4

The executables run fine with the MLton 20130715 release,
so it seemed like it might be a compiler regression...
I could bisect it if that would help & its not already something known

otherwise if it is actually a problem with mltonlib
let me know and i'll post it in the appropriate place

(gdb) bt
#0 returnAddressToFrameIndex (ra=16)

at /home/ratmice/git/mlton/install/usr/lib/mlton/include/amd64-main.h:35

#1 0x000000000042040f in GC_switchToThread ()
#2 0x00000000004022c3 in MLton_callFromC () at hello.1.c:702
#3 0x000000000040286d in glutDisplayFuncArgument () at hello.1.c:220
#4 0x00007ffff7d9e114 in fghcbDisplayWindow () from /lib64/libglut.so.3
#5 0x00007ffff7da1a39 in fgEnumWindows () from /lib64/libglut.so.3
#6 0x00007ffff7d9e72d in glutMainLoopEvent () from /lib64/libglut.so.3
#7 0x00007ffff7d9ef20 in glutMainLoop () from /lib64/libglut.so.3
#8 0x0000000000407867 in L_176 ()
#9 0x0000000000000001 in ?? ()
#10 0x0000000000402140 in fwrite@plt ()
#11 0x0000000000000000 in ?? ()

[MatthewFluet]

Almost certainly due to the new _import attribute of pure, impure, and reentrant. In particular, any _import-ed function that directly or indirectly calls an _export-ed function needs to be given the reentrant attribute (which makes sure that the calling ML context is properly suspended when control re-enters ML via the _export-ed function).

We've updated the foreign function interface to make the common case a tiny bit faster --- calling a C function that has no interaction with the ML runtime system. But, a consequence is that we need a little more work for the uncommon case, like callback functions that have an implicit interaction with the ML runtime system.

[ratmice]

Thanks Matthew, adding reentrant to the callbacks has fixed it, will send a patch for mltonlibs once i'm sure i haven't missed or overdone anything