Unable to deserialize session if it contains entities with lazy properties

[cremor]

I noticed that sometimes trying to deserialize a session fails with an exception like SerializationException: The object with ID 223 implements the IObjectReference interface for which all dependencies cannot be resolved. The likely cause is two instances of IObjectReference that have a mutual dependency on each other..

I'm not 100% sure about it, but it seems like that happens when the serialized session contains an entity that has lazy properties.

Sadly, the stack trace is not helpful:

at System.Runtime.Serialization.ObjectManager.GetCompletionInfo(FixupHolder fixup, ObjectHolder& holder, Object& member, Boolean bThrowIfMissing)
at System.Runtime.Serialization.ObjectManager.CompleteObject(ObjectHolder holder, Boolean bObjectFullyComplete)
at System.Runtime.Serialization.ObjectManager.DoFixups()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream)

I reproduced it with versions 5.2.7 and 5.3.3.

If I find any additional information I'll add it here later.
If anyone has an idea on how to narrow this down to a specific test case, please tell.

Target Framework is .NET 4.8
Test case: https://gist.github.com/bahusoid/55d8dfc3d02abfb270e4228fe50ab480

[bahusoid]

Do you have classes that implement IObjectReference in your code?

[bahusoid]

And what target framework?

[cremor]

No, my code doesn't use IObjectReference at all.
Target Framework is .NET 4.8

[bahusoid]

And can it be that deserialization happens after entity code is modified (like new properties were added)?

[bahusoid]

Also make sure that serialization/deserialization happens for the same NHibernate version.

[cremor]

My code flow is

1. Session is serialized.
2. Flush() is called.
3. If Flush() throws an exception (e.g. unique constraint violation) the session is deserialized.

So there are pending changes in the serialized session, otherwise Flush() would have never thrown an exception and therefore the deserialization would have never happened. But as far as I can tell (not 100% sure here) the pending changes don't have to be in the entities that have lazy properties.

Yes, serialization/deserialization always happens for the same NHibernate version. No, the entity mappings are not changed between serialization/deserialization. The session is just serialized to a MemoryStream, so it doesn't live after the process exits.

[bahusoid]

No idea what's goin on. I guess you should obtain dump of serialized session that fails - and then you can test it closely. If it's 100% reproducible or not. And you can provide custom surrogate to check when exception happens and what's inside your dump. Something like this:

var formatter = new BinaryFormatter
{
	SurrogateSelector = new SerializationInspector()
};
(ISession) formatter.Deserialize(serializedSession)


private class SerializationInspector : System.Runtime.Serialization.SurrogateSelector
{
	public override ISerializationSurrogate GetSurrogate(System.Type type, StreamingContext context, out ISurrogateSelector selector)
	{
		if (
			//typeof(BaseEntity).IsAssignableFrom(type)) && //maybe just log only entities
			!type.FullName.StartsWith("System.") //probably skip System classes
		)
			Console.WriteLine("Deserializing type: " + type.FullName);

		return base.GetSurrogate(type, context, out selector);
	}

}

[cremor]

I've tried your SurrogateSelector suggestion but can't see anything obvious wrong with the types that are passed there. The failing session has a few more distinct types, but none of those seem wrong (and they are all just my mapped entity classes, so there are no additional NHibernate types). The order of calls also doesn't seem to indicate anything because the last few types before the exception is thrown are always different.

But I have a 100% reproducible test case in my development system now. And I think that I narrowed it down. The crash only happens all of the following is true:

• An entity is mapped with a lazy property
• The same entity also has two many-to-one reference to itself (think of Predecessor and Successor properties)
• The session that is deserialized contained at least two of those entities and they referenced each other (e.g. entityA.Successor == entityB and entityB.Predecessor == entityA).

[bahusoid]

Good job! I've been able to reproduce it too on net461: https://gist.github.com/bahusoid/55d8dfc3d02abfb270e4228fe50ab480

[fredericDelaporte]

Does this happens with the legacy proxy factory too? (NHibernate.Bytecode.DefaultProxyFactoryFactory, see proxyfactory.factory_class)

[cremor]

The session deserialization doesn't throw an exception with the legacy proxy factory in my test case.

But there seems to be another big problem with it, because my entities with lazy properties then have all their properties (not just the lazy ones) reset to the default value after deserialization. Not that it matters since that code is deprecated anyway 😄

edit: I found #1481 which covers the properties reset bug. There you also commented that it won't be fixed for the legacy dynamic proxies.

[bahusoid]

Not really sure what's going on but with simplified tests case with only 2 entities FieldInterceptorObjectReference.GetRealObject is never called on deserialization (and deserialization ctor too).

[bahusoid]

It seems BinaryFormatter just can't deserialize circular references for objects implementing IObjectReference

I reproduced this issue with simple classes here imitating work of proxy for field interceptor.

[fredericDelaporte]

So this looks as a 5.2 regression, due to switching to the static proxy factory.

[bahusoid]

It seems inside FieldInterceptorObjectReference.GetBaseData we should detect field interceptor members and wrap them in new FieldInterceptorObjectWrapper class which has similar functionality of FieldInterceptorObjectReference but not implements IObjectReference (maybe extract base class from FieldInterceptorObjectReference)
Here is example of this implementation: https://gist.github.com/bahusoid/ecdd9119c30fef5e08585761a015b96b
Based on this not working example: https://gist.github.com/bahusoid/0f1e1fd25d9d3e5f1a147b0a0fea44cf