Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

F# option (FSharpOption<T>) fails to deserialize #1346

Closed
cata opened this issue Jan 28, 2016 · 5 comments
Closed

F# option (FSharpOption<T>) fails to deserialize #1346

cata opened this issue Jan 28, 2016 · 5 comments
Assignees
Labels

Comments

@cata
Copy link
Contributor

cata commented Jan 28, 2016

Adding an interface that uses FSharpOption<T> results in compile-time serializers being generated. This breaks the deserialization of the F# option type.

@cata cata changed the title Serialization breaks for grain interfaces with F# types F# option (FSharpOption<T>) fails to deserialize Feb 9, 2016
@cata
Copy link
Contributor Author

cata commented Feb 9, 2016

@ReubenBond - It would be great if you could give this a look. Repro available in #1417

I have tried to fix the issue but failed - a System.Security.VerificationException get triggered at deserialization time, with the message Operation could destabilize the runtime. The stack trace is:

Test Name:  UnitTests.Serialization.SerializationTestsFsharpTypes.SerializationTests_FSharp_IntOption_Some
Test FullName:  UnitTests.Serialization.SerializationTestsFsharpTypes.SerializationTests_FSharp_IntOption_Some
Test Source:    C:\code\ca-ta\orleans\test\Tester\SerializationTests\SerializationTests.FSharpTypes.cs : line 28
Test Outcome:   Failed
Test Duration:  0:00:03.61

Result StackTrace:  
at valueSet(FSharpOption`1 , Int32 )
   at UnitTests.GrainInterfaces.OrleansCodeGenMicrosoft_FSharp_Core_FSharpOptionSerializer`1.Deserializer(Type expected, BinaryTokenStreamReader stream) in C:\code\ca-ta\orleans\src\TestGrainInterfaces\Properties\orleans.codegen.cs:line 7760
   at Orleans.Serialization.SerializationManager.DeserializeInner(Type expected, BinaryTokenStreamReader stream) in C:\code\ca-ta\orleans\src\Orleans\Serialization\SerializationManager.cs:line 1525
   at Orleans.Serialization.SerializationManager.DeserializeInner[T](BinaryTokenStreamReader stream) in C:\code\ca-ta\orleans\src\Orleans\Serialization\SerializationManager.cs:line 1435
   at Orleans.Serialization.SerializationManager.DeserializeFromByteArray[T](Byte[] data) in C:\code\ca-ta\orleans\src\Orleans\Serialization\SerializationManager.cs:line 1709
   at Orleans.Serialization.SerializationManager.RoundTripSerializationForTesting[T](T source) in C:\code\ca-ta\orleans\src\Orleans\Serialization\SerializationManager.cs:line 2203
   at UnitTests.Serialization.SerializationTestsFsharpTypes.RoundtripSerializationTest[T](T input) in C:\code\ca-ta\orleans\test\Tester\SerializationTests\SerializationTests.FSharpTypes.cs:line 22
   at UnitTests.Serialization.SerializationTestsFsharpTypes.SerializationTests_FSharp_IntOption_Some() in C:\code\ca-ta\orleans\test\Tester\SerializationTests\SerializationTests.FSharpTypes.cs:line 29
Result Message: System.Security.VerificationException : Operation could destabilize the runtime.

I've run peverify on the grain interfaces assembly (the one containing the generated serializers), but no errors were found. Also, I've debugged the tests and the types seem correct... and yet the tests fail.

I have also experimented with temporarily suppressing interface code gen (by commenting the Orleans targets in TestGraininterfaces.csproj) and manually commenting out the generated OrleansCodeGenMicrosoft_FSharp_Core_FSharpOptionSerializer<T>. While this change did allow the tests to pass, attempting the same approach in our system did not work (still getting the exception in valueSet) - so I am quite stumped.

Needless to say, this issue prevents us (and I suspect others using F#) from upgrading to any Orleans version newer than 1.0.9.
Any suggestions on how to attack this issue (as well as any workarounds/hacks that may come to mind) are very welcome.

@cata
Copy link
Contributor Author

cata commented Feb 10, 2016

@ReubenBond - any feedback on this one? Note that #1424 and #1422 may be related?

@ReubenBond
Copy link
Member

Fixed in #1504, specifically this commit. There was a security/trust issue which was remedied by emitting the field acessor DynamicMethods into the same module as the field's type instead of into the declaring type's module. I'm not completely certain that there will never be a case where the declaring type has a higher security requirement than the field - it seems plausible. In that case we will have to investigate other options such as raising the trust level of Orleans.dll. Hopefully this all goes away in .NET Core.

@cata
Copy link
Contributor Author

cata commented Feb 28, 2016

@ReubenBond - thanks, and thanks for the commit pointer - I'll update #1417 shortly.

@ReubenBond
Copy link
Member

Fixed by #1504

@ghost ghost locked as resolved and limited conversation to collaborators Sep 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants