Bug 5667 - SerializationException: The object with ID 1 could not be resolved
Summary: SerializationException: The object with ID 1 could not be resolved
Status: RESOLVED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: mscorlib ()
Version: 2.10.x
Hardware: PC Windows
: Normal normal
Target Milestone: Untriaged
Assignee: Lluis Sanchez
URL:
Depends on:
Blocks:
 
Reported: 2012-06-15 07:09 UTC by Jeroen Frijters
Modified: 2015-03-16 18:37 UTC (History)
4 users (show)

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


Attachments
repro (4.93 KB, text/plain)
2012-06-15 07:09 UTC, Jeroen Frijters
Details
Prototype patch for ObjectManager.cs (1.95 KB, application/octet-stream)
2014-01-24 13:34 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 Jeroen Frijters 2012-06-15 07:09:22 UTC
Created attachment 2066 [details]
repro

When running the attached repro (isolated from IKVM's serialization support) it fails on Mono with:

Unhandled Exception: System.Runtime.Serialization.SerializationException: The object with ID 1 could not be resolved
  at System.Runtime.Serialization.ObjectManager.DoFixups () [0x00000] in <filename unknown>:0

On .NET it works as expected.
Comment 1 Neale Ferguson 2014-01-22 12:53:27 UTC
A client is encountering a similar problem. How was that test case created. In particular, the contents of "part3", especially the values:

0x73, 0x02, 0x00, 0x00, 0x00, 0x02, 0x02, 0x00, 0x00, 0x00, 0x09

The first 0x02 is part of the assembly Id of the preceding string. I'm not sure what the second 0x02 is. The subsequent 0x02 also appears to be an assembly id, the 0x09 the code for a subsequent object reference.

Tracing through the execution of the program up until the failure, it appears the status of an object is ReferenceSolvingDelayed so it is deemed "not ready" and fails in DoFixUps. Not sure if this is some failure in forward referencing or not. I am trying to decode the serialized object but am crapping out:

Element code:   00 (Header)

Element code:   12 (Assembly)
        Assembly ID:    2
        Assembly Name:  42956

Element code:   05 (External Object)
        Object ID:      1
        Class name:     java.io.InteropObjectOutputStream+DynamicProxy
        Field count:    2
        Field names:
                        $0
                        $data
        Type Tags:
                        Generic
                        Primitive Array
        Field Specs:
                        java.io.ObjectStreamClass
                        [Defined in 2]
                        No spec required
        External Id:    514
        Values:
                        Generic:   [0] 777
                        Primitive Array

I believe this is due to the way may decoding is handing the external object. I am following the guide at http://primates.ximian.com/~lluis/dist/binary_serialization_format.htm but things aren't matching up they way it shows.
Comment 2 Neale Ferguson 2014-01-22 14:47:17 UTC
I think I worked out the decode program. It shows the serialized object looks like (see below). Given object 1 is the external object java.io.InteropObjectOutputStream+DynamicProxy, does that mean it cannot find it anywhere?

Element code:   00 (Header)

Element code:   12 (Assembly)
	Assembly ID:    2
	Assembly Name:  42956

Element code:   05 (External Object)
	Object ID:      1
	Class name:     java.io.InteropObjectOutputStream+DynamicProxy
	Field count:    2
	Field names:
			$0
			$data
	Type Tags:
			Generic
			Primitive Array
	Field Specs:
			java.io.ObjectStreamClass
			[Defined in 2]
			Byte
	External Id:    2
	Values:
			Generic:   [9] 3
			Primitive Array: <9> [4]

Element code:   05 (External Object)
	Object ID:      3
	Class name:     java.io.ObjectStreamClass
	Field count:    3
	Field names:
			$0
			$1
			$data
	Type Tags:
			Generic
			Object
			Primitive Array
	Field Specs:
			java.lang.Class
			[Defined in 2]
			No spec required
			Byte
	External Id:    2
	Values:
			Generic:   [9] 5
			Object:    [10] <null>
			Primitive Array: <9> [6]

Element code:   15 (Primitive Array)
	Object Id:    4
	Count:        3
	Type:         Byte
			10
			1
			0

Element code:   05 (External Object)
	Object ID:      5
	Class name:     java.lang.ClassSerializationProxy
	Field count:    2
	Field names:
			type
			sig
	Type Tags:
			Object
			String
	Field Specs:
			No spec required
			No spec required
	External Id:    2
	Values:
			Object:    [10] <null>
			[7] Ltest;

Element code:   15 (Primitive Array)
	Object Id:    6
	Count:        24
	Type:         Byte
			20
			1
			114
			1
			17
			0
			4
			116
			101
			115
			116
			70
			178
			235
			119
			180
			247
			197
			7
			2
			0
			0
			1
			0
Comment 3 Neale Ferguson 2014-01-24 13:34:13 UTC
It appears that the current code only allows for two passes of the records when trying to resolve things. However, for situations like the test case, this is insufficient: The problem appears to be that we have three external objects (with ids of 1, 3 and 5). External object (1) has a "ObjectRequired" dependency on (3) but (3) also has such a dependency on (5). (5) has no such dependency so is processed in the first pass (firstCicle == true). However, on the second pass (1) is still not resolvable as (3) is yet to be resolved and we throw the exception.

I propose that we eliminate a fixed number of passes and simply check that the number of unresolved objects just goes down with each pass. A prototype patch is attached and appears to work with the test case as it gives the same result as under .NET.
Comment 4 Neale Ferguson 2014-01-24 13:34:52 UTC
Created attachment 5916 [details]
Prototype patch for ObjectManager.cs
Comment 5 Miguel de Icaza [MSFT] 2014-01-24 14:21:37 UTC
Lluis, for your review.
Comment 6 Lluis Sanchez 2014-02-06 16:13:28 UTC
Neale, I think your fix is not completely correct. The "record == last" condition will be true only once, and I think that condition should be run every time a cycle is completed.

I wrote an alternative fix: https://github.com/mono/mono/pull/889

Like in the current implementation, object references are ignored in the first cycle, and then it keeps trying until there is a cycle in which no objects are resolved. Please let me know if the fix works for you.
Comment 7 Marek Safar 2015-03-16 18:37:25 UTC
Included in Mono 3.12