Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign up2018.3: Initialization message in the console is constantly being shown #990
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unity case #1113071
The initialization message in the console is constantly being shown, instead of only showing up once when Unity first starts up. It looks like the ApplicationCache object that keeps the "is this our first load in this Unity session" state is being recreated over and over again, so we always think that this is a first run.
This is also having the side effect of rotating the logs every time the domain reloads, resetting all the metrics, and any other actions we usually only take when a Unity session first starts up. This miiight also be the cause for some weird crashes that we've had reports on.
This is only happening on 2018.3. I've tracked down the problem to a change in the way Unity is initializing custom attributes, specifically the ones that we have in our cache objects to mark where the cache file should be saved.
Before, the custom attribute would be initialized whenever we called
GetCustomAttributesourselves in https://github.com/github-for-unity/Unity/blob/master/src/UnityExtension/Assets/Editor/GitHub.Unity/ScriptObjectSingleton.cs#L95In 2018.3 it looks like Unity is eagerly creating instances of any custom attributes it finds very early in the project loading phase, before anything else is running. In our
LocationAttributeconstructor we reference the environment cache object (EntryPoint.ApplicationManager.Environment). This causes the singleton to be created, but Unity is creating a broken object with missing internal data, and then it tries to create it again, and again, and again... we end up with multiple managed instances of the same broken native object, and end up with duplicate information. This is happening with singletons that are not backed by a physical file and only live in memory (so they never go throughInternalEditorUtility.LoadSerializedFileAndForget).The workaround is move the logic out of the attribute constructor and into a property, so it doesn't run at this early time that is causing things to break.