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

[Wesley W. Terpstra]

On Fri, Oct 24, 2008 at 9:45 AM, Nicolas Bertolotti
<Nicolas.Bertolotti at mathworks.fr> wrote:
>> 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?

Lucky in the sense that you didn't do any of the things that would
have caused problems.

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

Well, I would try creating my own DLL that proxies calls to the DLL
which hangs. Then I'd stick print statements before passing the call
to the real DLL and after it returns. I'd especially make sure to
print the arguments so I could see if something strange was being
passed.

With this DLL wrapper, I would compare traces between the broken and
working programs. If the call sequence or parameters is different at
some point before the crash, I would investigate why.

Since you say the problem is intermittent, I would also be concerned
about garbage collection. Do you only ever call from SML->C or do you
also sometimes call from C->SML? It's my understanding that if you
call from C->SML, any pointers you had into the ML heap (vectors or
strings you received) are invalidated.

Another thing to check would be to run the program with '@MLton
gc-messages --'. You could then compare the good and bad programs to
see if garbage collection is happening around the hang of the bad
program, but not the good program.

>> You could also try -codegen c and/or -codegen bytecode.
> The issue does not reproduce with -codegen c.

I'm not sure what this means.

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

If the problem is memory corruption, you might try MLton revision
r6940. The subsequent revision changed how memory is managed under
win32.

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

This is my personal hope. ;-)