IN-66702: fully immersive app crashes when loading into scene with visual scripting objects

I’ve been investigating another crash and found a similar crash that I finally found a repro project for. The crash happens after loading into a scene containing a visual scripting object, after having been in a different scene. The app will crash on device with the following error:

-[IOGPUMetalCommandBuffer setProtectionOptions:], line 562: error 'setProtectionOptions: with uncommitted encoder'
-[IOGPUMetalCommandBuffer setProtectionOptions:]:562: failed assertion `setProtectionOptions: with uncommitted encoder'

(note this is similar to another issue someone brought up)

I have created a repro project (and bug report IN-660702) with the latest visionOS plugin (1.0.3) and Unity 2022.3.18:

Simply open the project, check Development Build, and build to device. You’ll see the crash after sitting in the blue scene for 3 seconds. If you then go into visual_scene02.unity and disable the game object (with the visual script) named “prefab02_CRASH_IF_ENABLED” and build, the crash goes away.

Any help is MUCH appreciated as this is a blocker for our app. @mtschoen

Hi - I know there is a lot going on (!) but does anyone at Unity have any updates on this? I saw that the bug got an internal ID created for it…
The main questions I have is whether it looks like there is a workaround for this and/or whether a fix may come in the relative short term. This affects our release plans, so anything you can provide helps (even if its “we can repro, but don’t know what the issue is yet!”). Thanks :pray:

Thanks for the reminder. As you say there’s a lot going on :upside_down_face:

I’m taking a look at your repro project now, and I can reproduce the issue. No progress yet on finding a root cause or a fix, but oftentimes just replicating the issue is half the battle. :slight_smile:

I’ll update this thread again when I have more info. Thanks for your patience!

1 Like

Thanks for the update! No idea if this is right, but I suspect there might be a memory leak or uninitialized data at play here. This is because a similar crash occurs in our app and only happens outside the debugger, and would crash at a slightly different time in our first update after a scene transition. Can’t say for sure, but maybe that’s a clue?

This sounds a bit like the app crashes when opening control center issue. There’s a safety catch in the CompositorServices system that will kill the app if it hasn’t presented frames quickly enough. The idea is that an app that is too slow or hung will present head-locked content, which will make the user sick. So if the system thinks you’re in such a state, it will kill the app. In the case of the control center crash, we pause Unity, thus no more rendering, and the system kills the app. The crash does not occur in the debugger because the system makes an exception when the debugger is attached. You may even notice the dialog that appears saying “content may be head-locked while debugging” or something like that.

So anyway I’d wager that other crash is Unity taking too long to load the next scene, and getting killed by the OS. Have you tried loading that scene asynchronously?

As for this crash, it’s definitely some sort of issue with the command buffer, since it causes the Metal API to hit a nullref internally. There’s a chance we get better feedback from the device, so I’m going to try that today.

ohhhh I think you may be right about our other case. We DO load the scene asynchronously, but have a HUGE glitch on the first frame after the scene loads (we black out the screen during this, which has been fine on other platforms). I guess we gotta fix that glitch then! Thanks for the tip on that one

Good news, everyone! I found a workaround for this crash. Hopefully it solves it in your real project, since it’s a weird one. I saw OnGUI in one of the stack traces, and found that there is one (and only one) OnGUI method in the VisualScripting package. If I delete it, the crash stops happening.

You should be able to do the same on your end. “Embed” the VisualScripting package by copying it from Library/PackageCache/com.unity.visualscripting@1.9.1 to Packages/com.unity.visualscripting so that you can modify the C# code. Then comment or delete the whole OnGUI method on line 12 of com.unity.visualscripting/Runtime/VisualScripting.Core/Listeners/GlobalMessageListener.cs.

I’m going to try and figure out why this is causing the crash, and hopefully find a fix at a lower level, but for now, hopefully, this should unblock you. IMGUI doesn’t work in VR, anyway, so I doubt you’ll miss it :slight_smile:

Thanks for reporting this issue, and good luck!

1 Like

Thanks for finding the workaround, much appreciated!! I’ll give this a go soon :raised_hands:

That’s great news ! Thanks for the workaround, we’ll test it ASAP !!

Hi - quick update: between this workaround and reducing our glitches when levels start (where the OS would just kill the process), we’re no longer crashing transitioning from level to level. @mtschoen let us know if an official fix to the visual scripting crash makes it way in, but we’ll keep this workaround in for now :slight_smile:
thanks!!

Thanks for the update! I still haven’t tracked down why that OnGUI crashes things, but we’ll let you know when we’ve fixed it.

I can confirm OnGUI in a different monobehaviour, nothing to do with visual scripting, was crashing our app as well.

Would it be possible to submit a bug with a project that reproduces the issue? I did some basic tests with OnGUI methods last month when I was looking into this issue, but I couldn’t replicate the VisualScripting crash. If I can see how your OnGUI code was crashing, it might help track down and fix the underlying issue. Even if you can just provide the C# script for that OnGUI method (provided it will replicate the crash) that would be greatly appreciated!

Thanks!