Editor crash followed by exception on restart

[William Besnard]

Hi,

I dont have much for you guys, but I’m reporting anyway:

Unity crashed during play, and then when restarting it, two exception popped up.

The version I use is 2019.1.8f1, and unfortunately the project is too big for me to send you a sample. I can however grant you access to the Git repo if needed.

I am using the last version of Odin on the asset store (2.0.20), no editor only mode, and heavily using the serialized scripts

I attached the crash dumps just in case.

---

ArgumentNullException: Value cannot be null.

Parameter name: unityObject
Sirenix.Serialization.UnitySerializationUtility.SerializeUnityObject (UnityEngine.Object unityObject, Sirenix.Serialization.SerializationData& data, System.Boolean serializeUnityFields, Sirenix.Serialization.SerializationContext context) (at C:/Sirenix/OdinSerializer/OdinSerializer/Utilities/Misc/Cache.cs:56)
Sirenix.OdinInspector.SerializedMonoBehaviour.UnityEngine.ISerializationCallbackReceiver.OnBeforeSerialize () (at C:/Sirenix/OdinSerializer/OdinSerializer/Unity Integration/SerializedUnityObjects/SerializedMonoBehaviour.cs:44)

‌

---

FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
System.Convert.FromBase64_Decode (System.Char* startInputPtr, System.Int32 inputLength, System.Byte* startDestPtr, System.Int32 destLength) (at <1f0c1ef1ad524c38bbc5536809c46b48>:0)
System.Convert.FromBase64CharPtr (System.Char* inputPtr, System.Int32 inputLength) (at <1f0c1ef1ad524c38bbc5536809c46b48>:0)
System.Convert.FromBase64String (System.String s) (at <1f0c1ef1ad524c38bbc5536809c46b48>:0)
Sirenix.Serialization.UnitySerializationUtility.DeserializeUnityObject (UnityEngine.Object unityObject, System.String& base64Bytes, System.Collections.Generic.List1[UnityEngine.Object]& referencedUnityObjects, Sirenix.Serialization.DataFormat format, Sirenix.Serialization.DeserializationContext context) (at C:/Sirenix/OdinSerializer/OdinSerializer/Utilities/Misc/DoubleLookupDictionary.cs:111) Sirenix.Serialization.UnitySerializationUtility.DeserializeUnityObject (UnityEngine.Object unityObject, Sirenix.Serialization.SerializationData& data, Sirenix.Serialization.DeserializationContext context, System.Boolean isPrefabData, System.Collections.Generic.List1[T] prefabInstanceUnityObjects) (at C:/Sirenix/OdinSerializer/OdinSerializer/Utilities/Misc/DoubleLookupDictionary.cs:101)
Sirenix.Serialization.UnitySerializationUtility.DeserializeUnityObject (UnityEngine.Object unityObject, Sirenix.Serialization.SerializationData& data, Sirenix.Serialization.DeserializationContext context) (at C:/Sirenix/OdinSerializer/OdinSerializer/Utilities/Misc/DoubleLookupDictionary.cs:83)
Sirenix.OdinInspector.SerializedMonoBehaviour.UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize () (at C:/Sirenix/OdinSerializer/OdinSerializer/Unity Integration/SerializedUnityObjects/SerializedMonoBehaviour.cs:37)

[William Besnard]

One more thing: shortly after reopening the editor, Unity crashed again, but the next time I restarted it the exceptions were gone. I am experiencing significantly more crashes on the last version, I don’t know what causes it just yet.

[Tor Esa Vestergaard]

Thanks for reporting this issue. I've tried changing a few things and adding some try-catch clauses around the Convert.FromBase64String call that's failing, that'll log the faulty string in question.

If you contact me on Discord, I can send you a build that contains this potential fix/extra debugging code. Ideally, it should both protect against the crash/uncaught exception, and also help us figure out what might be causing the data string to be corrupted.

[Antonio Rafael Antunes Miranda]

Was this resolved in Discord?

[Tor Esa Vestergaard]

I’ve not seen any reports of bugs in this general category (corrupt serialization data) for a long time now. My best guess is that this would be related to a thread-safety issue in the serializer that was fixed in the late 2.1.x patches, after which these sorts of reports largely went away. Let’s mark this resolved for now unless it rears its head again.