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

[Nicolas Bertolotti]

Good news first ...

I modified my code to use the "public" scope where this was needed and removed my patch in x86-generate-transfers.fun.

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.

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.

Now, my binary still freezes at the end of its execution under some circumstances.

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

I added some "print" and the last message I get is the one I put just before the call to the import. The C function itself, which also contains a print at the very beginning, never prints anything so I guess it is not even called.

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.

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

Thanks for your help

Nicolas

> -----Original Message-----
> From: mlton-bounces at mlton.org [mailto:mlton-bounces at mlton.org] On Behalf
> Of Nicolas Bertolotti
> Sent: Wednesday, October 22, 2008 4:14 PM
> To: Wesley W. Terpstra
> Cc: mlton at mlton.org
> Subject: RE: [MLton] Compilation crash with FFI on Windows with latest SVN
> revision (r6960)
>
> I have never heard about those "public" and "external" scopes. Have they
> been introduced recently ?
>
> The same piece of code used to build and run fine with MLton 2007. That's
> why I am asking (in my point of view, it can be considered as a
> regression).
>
> I am going to perform some additional tests and let you know.
>
> Thanks
>
> Nicolas
>
> > -----Original Message-----
> > From: Wesley W. Terpstra [mailto:wesley at terpstra.ca]
> > Sent: Wednesday, October 22, 2008 3:42 PM
> > To: Nicolas Bertolotti
> > Cc: mlton at mlton.org
> > Subject: Re: [MLton] Compilation crash with FFI on Windows with latest
> SVN
> > revision (r6960)
> >
> > On Wed, Oct 22, 2008 at 2:43 PM, Nicolas Bertolotti
> > <Nicolas.Bertolotti at mathworks.fr> wrote:
> > > It seems that the latest SVN revision prefixes all symbols with <
> __imp
> > >
> > > during code generation.
> >
> > That's correct.
> >
> > > This includes FFI functions which do not use the stdcall convention
> > which
> > > does not appear to be correct (simple C function defined in an
> external
> > C
> > > file that is given to MLton together with the SML sources).
> >
> > You are using the wrong symbol scope. Please change your _import
> > "somefn" : ... to _import "somefn" public : ... The problem you see is
> > because _import default to external, which means it needs __imp__ to
> > be fetched from a DLL. See http://mlton.org/LibrarySupport for some
> > (bad) documentation.
> >
> > > Anyway, this is just a tree in the forest (I'm not sure this
> expression
> > > makes sense in english) because the resulting binary simply freezes.
> >
> > Can you provide more details? The linking problem you describe should
> > be unrelated to the freeze. What was the programming doing when it
> > froze?
> >
> > > Please note that this regression is quite recent as the binary used to
> > run
> > > almost fine using revision 6698 (I know it is the one that introduced
> an
> > > effective Win64 support but I am really talking about Win32 binaries).
> > >
> > > ... and when I say "almost", this is because we experience some
> sporadic
> > > failures (the binary freezes) during FFI calls on some machines.
> >
> > If it froze before, it's quite possible that recent changes just made
> > this sporadic behavoiur ... more reliable. ;-)
>
> _______________________________________________
> MLton mailing list
> MLton at mlton.org
> http://mlton.org/mailman/listinfo/mlton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: essai.zip
Type: application/x-zip-compressed
Size: 1736 bytes
Desc: essai.zip
Url : http://mlton.org/pipermail/mlton/attachments/20081022/4e47a582/essai.bin