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

[Nicolas Bertolotti]

Case closed ...

I finally identified that the issue could also occur with older version of MLton and that it was located in the DLL itself (unfortunately, the debug messages that were sent to stderr from the DLL did not get printed to the screen).

It seems that the issue was highly related to the execution speed of the binary and that some improvements in the memory handling and in our code itself have contributed to increase the frequency.

Thanks for your help.

Nicolas

> -----Original Message-----
> From: Wesley W. Terpstra [mailto:wesley at terpstra.ca]
> Sent: Friday, October 24, 2008 5:11 PM
> To: Nicolas Bertolotti
> Cc: mlton at mlton.org
> Subject: Re: [MLton] Compilation crash with FFI on Windows with latest SVN
> revision (r6960)
>
> 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. ;-)