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

[Nicolas Bertolotti]

> 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. =)

So, do you mean that the fact that I was able to import functions from .c files and from DLLs without specifying a scope was just a matter of being lucky?

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

It just enters a dead lock (not CPU resources used but the process is still running).

> 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?

Unfortunately, I can't provide it. Then, I understand that I have to debug by myself. That is why I am only asking for some useful hints to investigate 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.

The issue does not reproduce with -codegen c.

The same code compiled using MLton 2007 works fine. On the other hand, the code freezes within the DLL itself (when it calls a function for which I don't even have access to the source code), not at the FFI call.

Then, it may be some kind of latent bug that has been revealed with the new version of MLton but not a MLton bug.

Still investigating...

Thanks for your help.

Nicolas