NullReferenceException from AcceptEULAWindow.OnUpdate in Cloud Build

Issue #715 resolved
Dan Vicarel created an issue

I posted about this in #695, but figured I should just open a new Issue rather then necro that one 😛

I am using Odin 3.0.1.0 with Editor Only mode enabled on Unity 2020.1.8f1. I have build targets set up in Unity Cloud Build for iOS/Android, but both are timing out after ~5 hours. When I look at their complete build logs, I see the following error showing up over and over again as if in an infinite loop:

[Unity] (Filename: X Line: 0)
[Unity] NullReferenceException: Object reference not set to an instance of an object
[Unity]   at (wrapper dynamic-method) System.Object.UnityEditor.Toolbar_getter<get.parent.screenPosition>()
[Unity]   at (wrapper delegate-invoke) System.Func`1[UnityEngine.Rect].invoke_TResult()
[Unity]   at Sirenix.Utilities.Editor.GUIHelper.GetEditorWindowRect () [0x00000] in X:\Repositories\sirenix-development\Sirenix Solution\Sirenix.Utilities.Editor\GUI\GUIHelper.cs:219 
[Unity]   at Sirenix.OdinInspector.Editor.AcceptEULAWindow.OnUpdate () [0x00075] in X:\Repositories\sirenix-development\Sirenix Solution\Sirenix.OdinInspector.Editor\Windows\AcceptEula\AcceptEULAWindow.cs:51 
[Unity]   at (wrapper delegate-invoke) <Module>.invoke_void()
[Unity]   at UnityEditor.EditorApplication.Internal_CallUpdateFunctions () [0x00076] in /Users/bokken/buildslave/unity/build/Editor/Mono/EditorApplication.cs:332

I am not positive which OS Cloud Build runs on, but I assume its MacOS, since it has to be able to run Xcode. This build error did not show until I upgraded from Unity 2019.4 and Odin 2.x.

Comments (11)

  1. Tor Esa Vestergaard
    • changed status to open

    This is rather odd - we do a check for headless mode to prevent the EULA popup from happening in cases such as cloud builds, but it seems that it has continued past that check and is running into some other error that only happens due to it being a cloud build. We can add some mitigations for a case like this, but I am not sure we can fix it entirely without knowing exactly why it is giving such an odd error.

  2. Tor Esa Vestergaard

    I'll mark this as resolved for now; I've added an extra try-catch that catches exceptions like this and logs only a single error in a more controlled fashion and then stop, rather than just keeping going with attempts again and again as you were seeing.

  3. Dan Vicarel reporter

    @Tor Esa Vestergaard Unfortunately this Cloud Build issue is still occurring in 3.0.2.0. Its not happening in an infinite loop anymore; now its only happening once during my Edit Mode tests. Here are some more logs for context:

    1399: [Unity] Running tests for editmode
    1400: [Unity] Executing tests with settings: test mode = EditMode
    1401: [Unity] UnityEngine.DebugLogHandler:Internal_Log(LogType, LogOption, String, Object)
    1402: [Unity] UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
    1403: [Unity] UnityEngine.Logger:Log(LogType, Object)
    1404: [Unity] UnityEngine.Debug:Log(Object)
    1405: [Unity] UnityEditor.TestTools.TestRunner.CommandLineTest.Executer:InitializeAndExecuteRun(String[]) (at Library/PackageCache/com.unity.test-framework@1.1.18/UnityEditor.TestRunner/CommandLineTest/Executer.cs:45)
    1406: [Unity] UnityEditor.TestTools.TestRunner.CommandLineTest.TestStarter:UpdateWatch() (at Library/PackageCache/com.unity.test-framework@1.1.18/UnityEditor.TestRunner/CommandLineTest/TestStarter.cs:50)
    1407: [Unity] UnityEditor.EditorApplication:Internal_CallUpdateFunctions() (at /Users/bokken/buildslave/unity/build/Editor/Mono/EditorApplication.cs:332)
    1408: [Unity] (Filename: Library/PackageCache/com.unity.test-framework@1.1.18/UnityEditor.TestRunner/CommandLineTest/Executer.cs Line: 45)
    1409: [Unity] [MODES] Loading mode Default (0) for mode-current-id-High Hand Hold'em
    1410: [Unity] NullReferenceException: Object reference not set to an instance of an object
    1411: [Unity]   at (wrapper dynamic-method) System.Object.UnityEditor.Toolbar_getter<get.parent.screenPosition>()
    1412: [Unity]   at (wrapper delegate-invoke) System.Func`1[UnityEngine.Rect].invoke_TResult()
    1413: [Unity]   at Sirenix.Utilities.Editor.GUIHelper.GetEditorWindowRect () [0x00000] in X:\Repositories\sirenix-development\Sirenix Solution\Sirenix.Utilities.Editor\GUI\GUIHelper.cs:219 
    1414: [Unity]   at Sirenix.OdinInspector.Editor.AcceptEULAWindow.OnUpdate () [0x000b4] in X:\Repositories\sirenix-development\Sirenix Solution\Sirenix.OdinInspector.Editor\Windows\AcceptEula\AcceptEULAWindow.cs:57 
    1415: [Unity] Rethrow as Exception: An exception happened while attempting to open Odin's EULA popup window.
    1416: [Unity] UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
    1417: [Unity] UnityEngine.DebugLogHandler:LogException(Exception, Object)
    1418: [Unity] UnityEngine.Logger:LogException(Exception, Object)
    1419: [Unity] UnityEngine.Debug:LogException(Exception)
    1420: [Unity] Sirenix.OdinInspector.Editor.AcceptEULAWindow:OnUpdate() (at X:\Repositories\sirenix-development\Sirenix Solution\Sirenix.OdinInspector.Editor\Windows\AcceptEula\AcceptEULAWindow.cs:64)
    1421: [Unity] UnityEditor.EditorApplication:Internal_CallUpdateFunctions() (at /Users/bokken/buildslave/unity/build/Editor/Mono/EditorApplication.cs:332)
    1422: [Unity] (Filename: X Line: 0)
    

  4. Tor Esa Vestergaard

    Hmm, so we can now be sure that it does not detect this is a Cloud Build - IE, Cloud Builds are apparently not being run in headless mode and there is actually a graphics device? But even so, creating a Window instance is not possible? Very strange.

    How do you, in your code, detect that you are currently running in a Cloud Build instance? At the moment, we rely on the following code to determine whether we are in headless mode:

    private static bool IsHeadlessMode { get { return UnityEngine.SystemInfo.graphicsDeviceType == UnityEngine.Rendering.GraphicsDeviceType.Null; } }

    However, this is apparently not enough, and we need to add an additional check for this particular, aberrant cloud build context. Are you familiar with any method of detecting it?

  5. Dan Vicarel reporter

    @Tor Esa Vestergaard Well, the fact that this is occurring during Edit Mode tests might be a clue. Perhaps tests are run with graphics because somebody might be testing something about graphics. But I’m not positive. I was fairly certain that the rest of the Cloud Build process ran headless, however, when I did a simple Ctrl+F for “headless” in the Full Log of my latest build, there were no hits, which isn’t promising because I think they log all command-line args passed to the Unity executable.

    The best method I’ve found for running something only in Cloud Build is to use [pre- and post-export methods](https://docs.unity3d.com/2019.3/Documentation/Manual/UnityCloudBuildPreAndPostExportMethods.html). This isn’t a stateless check though, its more like passing a callback to Cloud Build, so I’m not sure how you could ensure something runs only outside of Cloud Build.

    If you like, I can add some logs to my Edit Mode tests to check the values of any relevant properties during those parts of the Cloud Build process. I would just need a list.

  6. Dan Vicarel reporter

    @Tor Esa Vestergaard

    So upon further research, I’m not sure that the absence of graphics hardware is really the condition you should use for suppressing the EULA window. Seems more like you should be testing for “batch mode”, wherein Unity already suppresses messages and UI that would require human input. I suggest replacing calls to your IsHeadlessMode property with calls to UnityEditorInternal.InternalEditorUtility.inBatchMode instead. I got this API from this Unity Forums post, and I have verified in my own code that this is actually a public Unity API, despite the “internal” in the name, and that it is true during Cloud Build execution.

    Please let me know what you think, but no rush, its Christmas Eve 😛.

  7. Tor Esa Vestergaard

    That makes sense - if you’ll contact me on Discord, I can send you a testing build with that change made so you can verify that it resolves the issue for you, if you wish.

  8. Log in to comment