Function returned by Microsoft.FSharp.Reflection.FSharpValue.PreComputeUnionConstructor throwing FatalExecutionEngineError when invoked

The function returned by Microsoft.FSharp.Reflection.FSharpValue.PreComputeUnionConstructor is throwing the following error very occasionally when used to create a value of type float option via reflection.

FatalExecutionEngineError occurred Message: Managed Debugging Assistant ‘FatalExecutionEngineError’ has detected a problem in ‘C:\dev\vs2015\src\repro\bin\Debug\repro.exe’. Additional information: The runtime has encountered a fatal error. The address of the error was at 0xf582d7f4, on thread 0xdaa0. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.

This seems to have started happening after I installed VS2015, however targeting earlier versions of either FSharp.Core or the .NET runtime makes no difference. I’ve also tried setting <useLegacyJit enabled="1"/> in the app.config due to the known bug in RyuJIT (http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/), however this also makes no difference. I’ve only tried this on Windows 7, so I don’t know if it’s OS specific. It happens in both Debug and Release build.

I’ve managed to create a reproduction of the error. Compile and run the project linked to below with the conditional compilation symbol ‘BUG’ defined, and it should fail with the above error. Then compile and run without ‘BUG’ defined to replace the use of FSharpValue.PreComputeUnionConstructor with equivalent non reflection based code, and the program will complete without error.

The project can be downloaded from here: https://www.dropbox.com/l/BXokpag4b4pFtBzeTJpion Note that it’s a 20Mb file as it contains 2 embedded data files which contain serialised arrays that trigger the error.

[leecow]

Hi @bmenees , yes, the fix is in yesterday’s 4.6.1 release.

[menees]

@leecow, is this fix in .NET 4.6.1 (since it was released on November 30)?