Hello there,
could anyone please explain the meaning of the following assert? It happens a lot during scene save in my debug version, so I would like to now how dangerous it is and where should I look for an issue with our assets.
Thanks!
Regards,
Tomas
Assertion failed: Assertion failed on expression: '(hierarchy.combinedSystemChanged | hierarchy.systemChanged[index]) == (hierarchy.combinedSystemChanged | gHasChangedDeprecatedSystem.Mask())'
UnityEngine.Object:smile:estroyImmediate(Object, Boolean)
UnityEngine.Object:smile:estroyImmediate(Object) (at D:/Unity-source/2017.3/artifacts/generated/common/runtime/UnityEngineObjectBindings.gen.cs:92)
TemporyBoundaryGizmo`1:smile:estroyAllGizmos() (at Assets/frameworks/sceneFramework/scripts/TemporyBoundaryGizmo.cs:162)
TemporyGizmos:RemoveTemporyGizmos() (at Assets/frameworks/sceneFramework/scripts/SceneRoot.cs:40)
SceneFrameworkSave:OnSaveScene() (at Assets/moonEditor/SceneFrameworkSave.cs:151)
SceneFrameworkSave:OnWillSaveAssets(String[]) (at Assets/moonEditor/SceneFrameworkSave.cs:24)
System.Reflection.MonoMethod:InternalInvoke(Object, Object[], Exception&)
System.Reflection.MonoMethod:Invoke(Object, BindingFlags, Binder, Object[], CultureInfo) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
System.Reflection.MethodBase:Invoke(Object, Object[]) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MethodBase.cs:115)
UnityEditor.AssetModificationProcessorInternal:OnWillSaveAssets(String[], String[]&, String[]&, Int32) (at D:/Unity-source/2017.3/Editor/Mono/AssetModificationProcessor.cs:147)
[D:/Unity-source/2017.3/Runtime/Transform/Transform.cpp line 1834]
Any assert you encounter is generally a bug in Unity. We’d like a bug report. I’ll ask relevant people to see how dangerous failing this assert is.
@Tautvydas-Zilys This assert is failing for us on Unity 2017.4.2f2 in UWP builds only, in a call to someTransform.SetParent(null). It also causes the build to crash (Unhandled win32 exception).
Unfortunately, creating a repro project for this is very time consuming since it only happens in UWP builds and those are a bit of a pain. 
Is there a bug report created for this anywhere? If we find anything about this we’ll let you know. We need it to not crash. 
This is the output info:
So… it seems that the assert failure and crash don’t happen if you play the UWP build in Release mode instead of Debug mode. At least in our case. It only took 5 and a half hours of boring builds to find this… x) We randomly decided to make a Release build and the error was gone.
Yay?
1 Like
Asserts are disabled in release builds - it doesn’t mean that the error went away, though. Unfortunately it’s not clear what the impact on this is, and we don’t have any existing bug reports on this :(.
I was getting this bug in 2017.2.0p2 whenever I called Instantiate with a parent included. Instantiating prefabs without parents and setting them after fixed most occurrences of this bug but it still showed up in one other place that I am unable to work out.
Moving to 2017.3.1p4 fixed that particular instance but created another assert crash elsewhere for seemingly no reason. Going to try release build and 2018.1
We understand that the error hasn’t gone away, but negative consequences don’t seem to exist so far. The functionality that was failing now works as expected and doesn’t crash. We are not totally confident about it, though.
We found a small repro project to be hard to create. 
We have to take away everything from the project until we can reproduce it with a minimal set of things, but these are UWP builds, which are VERY time consuming to make after each change.
I’ll try to make one later today, but can’t promise much.
Oh and we haven’t tried 2018 yet, due to incompatibilities being expected and our app being very close to release.
@Tautvydas-Zilys After some more pain I submitted a bug report. In our case it only happens on UWP builds but it should help.
Thanks, do you have a case #? I don’t need the link, just the number.
Seeing this in 2018.1.2f1 as well.
This turned out to be an incorrect assert. It’s totally harmless, though somewhat annoying. We have a fix in the pipeline.
1 Like