Bug 51622 - Tuple not serialized despite being marked as Serializable
Summary: Tuple not serialized despite being marked as Serializable
Status: RESOLVED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: mscorlib ()
Version: master
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Marek Safar
URL:
Depends on:
Blocks:
 
Reported: 2017-01-18 19:13 UTC by Neale Ferguson
Modified: 2017-01-24 03:04 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: Yes
Last known good build: C9


Attachments
Test case (680 bytes, text/plain)
2017-01-18 19:13 UTC, Neale Ferguson
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Neale Ferguson 2017-01-18 19:13:15 UTC
Created attachment 19386 [details]
Test case

In .NET and mono 4.4 the attached test case works without error. Under Trunk the following is received:

Unhandled Exception:
System.Runtime.Serialization.SerializationException: Type 'System.Tuple`2[[fail22.FaceDirection, 44902, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null],[System.Double, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]' in Assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.
  at System.Runtime.Serialization.FormatterServices.InternalGetSerializableMembers (System.RuntimeType type) [0x0004b] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.FormatterServices.GetSerializableMembers (System.Type type, System.Runtime.Serialization.StreamingContext context) [0x00091] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitMemberInfo () [0x0003d] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize (System.Object obj, System.Runtime.Serialization.ISurrogateSelector surrogateSelector, System.Runtime.Serialization.StreamingContext context, System.Runtime.Serialization.Formatters.Binary.SerObjectInfoInit serObjectInfoInit, System.Runtime.Serialization.IFormatterConverter converter, System.Runtime.Serialization.Formatters.Binary.ObjectWriter objectWriter, System.Runtime.Serialization.SerializationBinder binder) [0x00175] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize (System.Object obj, System.Runtime.Serialization.ISurrogateSelector surrogateSelector, System.Runtime.Serialization.StreamingContext context, System.Runtime.Serialization.Formatters.Binary.SerObjectInfoInit serObjectInfoInit, System.Runtime.Serialization.IFormatterConverter converter, System.Runtime.Serialization.Formatters.Binary.ObjectWriter objectWriter, System.Runtime.Serialization.SerializationBinder binder) [0x00007] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize (System.Object graph, System.Runtime.Remoting.Messaging.Header[] inHeaders, System.Runtime.Serialization.Formatters.Binary.__BinaryWriter serWriter, System.Boolean fCheck) [0x001c6] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream serializationStream, System.Object graph, System.Runtime.Remoting.Messaging.Header[] headers, System.Boolean fCheck) [0x00071] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream serializationStream, System.Object graph, System.Runtime.Remoting.Messaging.Header[] headers) [0x00000] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream serializationStream, System.Object graph) [0x00000] in <e3bbbd1c8572440d8b8fd1c86e3a9a73>:0 
  at fail22.MainClass.Main (System.String[] args) [0x0001c] in <36a6c1076560488eb894ddb399ad2fcb>:0 

A trace shows that the following test fails:

if ((GetAttributeFlagsImpl() & TypeAttributes.Serializable) != 0)

GetAttributeFlagsImpl is returning a value different to what it did in 4.4. If I do the following in the IsSerializable method of type.cs:

Type type = this.GetType();
TypeAttributes attr = type.Attributes;
Console.Error.WriteLine("AttrFlags: {0}\nTypeAttr: {1}\nSerializable: {2}",
GetAttributeFlagsImpl(),attr);

I see:

AttrFlags: NotPublic, AnsiClass, Class, Public, BeforeFieldInit 
TypeAttr: NotPublic, AnsiClass, Class, SequentialLayout, Serializable, BeforeFieldInit

On 4.4 GetFlagsImpl() returns: 1056897 (0x102801)
On trunk: 1048577 (0x100001)
Comment 1 Aleksey Kliger 2017-01-18 20:57:51 UTC
Marek,

The switch to corert Tuple classes from referencesource (ddb72c43c8d092c651cb8abfc0d4dd7feee4aa5e) seems to be responsible.

The Tuple classes in corert/src/System.Private.CoreLib/src/System/Tuple.cs
don't have a SerializableAttribute.
Comment 2 Neale Ferguson 2017-01-19 16:19:40 UTC
Adding the [Serializable] attribute to those methods (unsurprisingly) fixes the problem.
Comment 3 Marek Safar 2017-01-20 15:19:37 UTC
Tracking as https://github.com/dotnet/corert/issues/2549
Comment 4 Marek Safar 2017-01-24 03:04:25 UTC
Fixed in master