[MLton] Compilation crash with FFI on Windows with latest SVN revision (r6960)

[Wesley W. Terpstra]

On Wed, Oct 22, 2008 at 8:01 PM, Nicolas Bertolotti
<Nicolas.Bertolotti at mathworks.fr> wrote:
> Now, the code runs (almost) fine using MLton r6960. I am still surprised that "public" is not the default as the new behavior introduces an incompatibility with the existing official release.

Well, picking 'public' as the default would break _import from
libraries. Either way something that used to "work" won't. As the old
_import didn't have public/external, you would have problems if you
tried to import a variable (as opposed to a function) or take the
address of functions. The new syntax at least gives you a compile
error as opposed to a bug that lurks in wait. =)

> I think that most users generally simply want to write a small piece of C code and compile the .c file together with their SML files where they import the corresponding function. I am afraid that the new default behavior is not as intuitive as the previous one.

Maybe. It's also pretty usual to do _import "sqlite3_open" or similar, though.

> The issue occurs when it calls, from the SML code, a function that is included in a Windows DLL.

Is this function maybe an stdcall function? Try _import "fn_in_a_dll"
external stdcall : ...

> In my big application, the DLL publishes 2 functions. The call to the first one is well executed and the binary freezes when it tries to call the second one.

What do you mean freezes? It pegs the CPU at 100%? Crashes? Simply stops?

> I tried to reproduce the problem on a small sample but it unfortunately didn't work. Anyway, you will find it as an attachment. It basically shows how the code is designed. If the sample did reproduce the issue, it would print the message "Calling foo2()..." and then freeze.

I need to be able to debug the freeze in order to fix it... You could
also try to debug the program yourself and set a break-point at the
function call. It's pretty much impossible to diagnose from the
information you've provided so far.

Is this code covered by an NDA? Can we see it?

> I am afraid there are a number of things the big application does which cause it to go through other parts of the x86 code generator and generate some kind of memory or stack corruption that can not be easily reproduced with a small sample.

You could also try -codegen c and/or -codegen bytecode.