UE4 crash when using VR Preview since last Oculus app update
Hello, this has been impossible to use the VR preview anymore since the last Oculus app update. Every time you use the VR preview for a second time, Unreal will crash. Please fix this asap, it's making debugging in VR a nightmare. The issue is on 4.27 but I already discussed with several persons having the issue on different versions of UE5.9.4KViews12likes23CommentsKnown Issue: Closing Steam VR crashes Dash
Hi everyone! We're seeing a small group of Steam VR users finding that Dash is crashing on headset and that their PC is becoming unresponsive once they quit the app. The team is working on identifying and fixing the root cause of this issue, and right now the investigation shows that this is likely related to Hardware Accelerated GPU Scheduling being enabled when using certain Nvidia GPUs. If you're having this issue, there is a workaround In the meantime! You can prevent this happening by disabling the Hardware Accelerated GPU Scheduling feature. To do so, follow these instructions. If you need any further help or have noticed other bugs around Steam VR, please comment below. Let me know if you have any questions!19KViews9likes15CommentsOculus Link crashes when Unity enters PlayMode and does not work until Unity Editor is restarted
As described in the discussion title. More often than not does Oculus Link crash out of existence when entering Unity´s play mode. The setup is as follows. I use an official Oculus USB-C cable to connect my Oculus Quest to my Windows10 PC while using any Unity version past 2019 (prev. versions not tested) with the Unity build in XR Oculus package (not the Oculus Integration from the AssetStore). The idea now is that when I press Play in the Unity editor I will be able to test my app in a similar way as if it was installed on the Quest directly. This worked without any issues until some recent Oculus update (can´t tell when exactly) which apparently let´s the Oculus Link app crash very often regardless of Unity Version or complexity of the scene. The Quest itself gets thrown back into the standard Quest homescreen, Unity will just be stuck on a black screen and the Oculus app will restart anew after its disappearance. That by itself is annoying enough. But the main problem is that I cannot just exit Unity play mode, reestablish the Oculus Link and enter play mode again to fix the problem. Oh no! The major time consuming part of this misbehavior is that once it crashed I need to close the Unity editor, then restart Oculus Link, then start the Unity editor again. Imagine having a semi-big project with an active collaborate service checking for changes every time Oculus Link decides to crash and forcing you to restart the editor. Please help. I do not know how to solve this. If someone at least knows a workaround or fix that does spare me from restarting the editor, I´d be more than happy.5KViews3likes4CommentsMeta's handling of xrCreateVulkanInstance requests duplicate extensions, causing crashes
Trying to execute a VR game with Vulkan when OpenXR runtime is set to Meta causes crashes before the application starts, although not always. I have checked with an empty Unity project that it only happens with Vulkan and Meta runtime environment. After much searching, it led me to this thread on the Unity forums from late 2023, early 2024, where someone from the support team clarifies that it is a problem on Meta's part, and they make that clear in this bug report. It's been over a year since this bug was reported to Meta by Unity itself and it still hasn't been fixed, we're unable to progress in the development of our game because of this bug. We need a fix for this critical bug ASAP.143Views3likes0CommentsV56 and up, Quest Pro Link stability
Hello, I've been developing an app at work for PCVR, we're using Quest Pros and extremely high end PCs with one router that has four WiFi bands, hardware is not an issue here, all new and a bit of an overkill performance-wise. The problems we're having are crashes and stability of tracking when in link, the headsets repeatedly reset and adjust their position as if pressing recenter. We were using spatial anchors before but that can no longer be utilized as they cause our app AND oculus desktop app to crash. We're building on Unreal Engine 5.2 with developer features turned on so we can use hand tracking and anchors on PC. We tested for what could cause the crashes and found out that it is Quest system version, even with the newest plugin in Unreal the app runs smoothly on v55 but still stashes on v56 and v57. Is this a known issue or are we the first to encounter it? Any help with solving the crashes would be appreciated, we had to code our own provisional spatial anchors for now but the instability with link makes them an unviable option.2.3KViews3likes2CommentsSystem crash help, and how to get system logs from users?
TLDR; I'd like for a way for my game code (unity) to be able to pull logs out of logcat, not tagged by my game (with the user's permission).....and...maybe someone from Oculus can help resolve why these crashes are happening at all. During the playing of my game, there are sometimes hard crashes to the system, or even full freezes where users have to hard restart the headset. I don't know what is causing it. It isn't repeatable consistently....and while it happens more during my game, the stack trace doesn't mention my game at all when it does crash. I'd like to be able to, on the next game session, offer the user a button that says "would you like to send crash logs from the previous session to help us resolve it?" I already have a system that allows them to send logs from my own logging...but the few crashes that I have seen, the logs weren't fired from the application. ..but I don't know how to, and if it's possible to pull system ADB logs, from c# unity game context. When I force a crash from the game through various means (on purpose) the stack mentions the game Build fingerprint: 'oculus/vr_monterey/monterey:7.1.1/NGI77B/358570.9320.0:user/release-keys' Revision: '0' ABI: 'arm' pid: 7827, tid: 7842, name: UnityMain >>> quest.eleven.forfunlabs <<< signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xeaa8afb4 r0 cfdfff73 r1 d1d9adc8 r2 eaa8bc44 r3 00000001 r4 eaa8b558 r5 eaa8b560 r6 eaa8b60c r7 eaa8b588 r8 eaa8bc44 r9 d1d9adc8 sl d1d9adc8 fp 00000007 ip ec4b0dd0 sp eaa8af00 lr ec46d70d pc ec467990 cpsr 200f0030 backtrace: #00 pc 0003f990 /system/lib/libc.so (__vfprintf+27) #01 pc 00045709 /system/lib/libc.so (vsnprintf+136) #02 pc 000040f9 /system/lib/liblog.so (__android_log_vprint+40) #03 pc 002eedfc /data/app/quest.eleven.forfunlabs-1/lib/arm/libunity.so #04 pc 00773d50 /data/app/quest.eleven.forfunlabs-1/lib/arm/libunity.so #05 pc 002ee72c /data/app/quest.eleven.forfunlabs-1/lib/arm/libunity.so #06 pc 00001d0c [anon:thread signal stack:eaa8b000] below is one from when it crashed during the QA testing but when it crashes spontaneously during game play it looks like the large paste above...or like this one (specifically captured during a crash) --------- beginning of crash 08-21 07:55:40.946 709 5076 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 5076 (CamSlamCfsMgr) 08-21 07:55:41.428 5662 5662 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 08-21 07:55:41.429 5662 5662 F DEBUG : Build fingerprint: 'oculus/vr_monterey/monterey:7.1.1/NGI77B/333700.3780.0:user/release-keys' 08-21 07:55:41.429 5662 5662 F DEBUG : Revision: '0' 08-21 07:55:41.429 5662 5662 F DEBUG : ABI: 'arm64' 08-21 07:55:41.429 5662 5662 F DEBUG : pid: 709, tid: 5076, name: CamSlamCfsMgr >>> /system/bin/trackingservice <<< 08-21 07:55:41.430 5662 5662 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 08-21 07:55:41.430 5662 5662 F DEBUG : x0 0000000000000000 x1 00000000000013d4 x2 0000000000000006 x3 0000000000000008 08-21 07:55:41.430 5662 5662 F DEBUG : x4 0000007f87802140 x5 0000007f6813c380 x6 0000000000000001 x7 00000001a32607b8 08-21 07:55:41.430 5662 5662 F DEBUG : x8 0000000000000083 x9 0000007f72d02450 x10 3d4648a5ea451e80 x11 0000000000000000 08-21 07:55:41.430 5662 5662 F DEBUG : x12 0000000000000001 x13 0000000000000020 x14 ffffffffffffffdf x15 0000007f87d68810 08-21 07:55:41.430 5662 5662 F DEBUG : x16 0000007f87d5dec0 x17 0000007f87cff824 x18 0000000000000098 x19 0000007f72d024f8 08-21 07:55:41.430 5662 5662 F DEBUG : x20 0000000000000006 x21 0000007f72d02450 x22 0000000000000000 x23 0000000000000004 08-21 07:55:41.430 5662 5662 F DEBUG : x24 0000007f869ee6e0 x25 00000000000003dc x26 000000000000f700 x27 00000000000003e8 08-21 07:55:41.430 5662 5662 F DEBUG : x28 0000007f711ae602 x29 0000007f72cff410 x30 0000007f87cfc5d8 08-21 07:55:41.430 5662 5662 F DEBUG : sp 0000007f72cff3f0 pc 0000007f87cff82c pstate 0000000060000000 08-21 07:55:41.447 5662 5662 F DEBUG : 08-21 07:55:41.447 5662 5662 F DEBUG : backtrace: 08-21 07:55:41.447 5662 5662 F DEBUG : #00 pc 000000000007982c /system/lib64/libc.so (tgkill+8) 08-21 07:55:41.447 5662 5662 F DEBUG : #01 pc 00000000000765d4 /system/lib64/libc.so (pthread_kill+64) 08-21 07:55:41.447 5662 5662 F DEBUG : #02 pc 0000000000024a80 /system/lib64/libc.so (raise+24) 08-21 07:55:41.448 5662 5662 F DEBUG : #03 pc 000000000001cd8c /system/lib64/libc.so (abort+52) 08-21 07:55:41.448 5662 5662 F DEBUG : #04 pc 00000000008f780c /system/lib64/libMontereyTracker.so (_ZN9visionlog12doLogFatalOpIRiS1_JEEEvOT_PKcOT0_S5_S5_DpOT1_+108) 08-21 07:55:41.448 5662 5662 F DEBUG : #05 pc 0000000000d09e18 /system/lib64/libMontereyTracker.so 08-21 07:55:41.448 5662 5662 F DEBUG : #06 pc 000000000117a0b8 /system/lib64/libMontereyTracker.so (_ZN10perception16ImagePyramidBaseIhNS_18ImageHalfSample3x3EE17runInitializationEN3gsl4spanIKPS2_Lln1EEERKNS1_10ParametersENS_31ImagePyramidInitializationStateE+244) 08-21 07:55:41.448 5662 5662 F DEBUG : #07 pc 0000000000ce9238 /system/lib64/libMontereyTracker.so (_ZN10perception8vio_toon16PatchMatcherBolt5matchERKNS0_20PatchMatcherSettingsEN3gsl4spanIKNS0_10MatchQueryELln1EEENS6_IPKNS_11CameraModelELln1EEENS6_IKPNS_16ImagePyramidBaseIhNS_18ImageHalfSample3x3EEELln1EEENS6_IN8coretech12RefuseReasonELln1EEENS6_INS0_16PatchMatchResultELln1EEE+1424) 08-21 07:55:41.448 5662 5662 F DEBUG : #08 pc 0000000000cedb58 /system/lib64/libMontereyTracker.so (_ZN10perception8vio_toon12PatchTracker5trackENS_6IdTmplItNS0_13FrameSetIdTagELb1EEENS0_17VersionedAnchorIdEN3gsl4spanIKN4TooN3SE3IdEELln1EEENS7_IPKNS_11CameraModelELln1EEENS7_IPNS_16ImagePyramidBaseIhNS_18ImageHalfSample3x3EEELln1EEEbRNSt6__ndk16vectorINS0_16TrackMeasurementENSM_9allocatorISO_EEEERNSN_INS0_26TrackToLandmarkAssociationENSP_IST_EEEERNSN_INS0_18RelativeAnchorDataENSP_ISX_EEEERNSN_INS0_7TrackIdENSP_IS11_EEEE+924) 08-21 07:55:41.448 5662 5662 F DEBUG : #09 pc 00000000009d35dc /system/lib64/libMontereyTracker.so (_ZN5viper26MontereyLagunaTrackTracker5trackENS_13LiveTimestampEN10perception6IdTmplItNS2_8vio_toon13FrameSetIdTagELb1EEEN3gsl4spanIKN4TooN3SE3IdEELln1EEENS8_IPKNS2_11CameraModelELln1EEENS8_INSt6__ndk110shared_ptrINS2_16ImagePyramidBaseIhNS2_18ImageHalfSample3x3EEEEELln1EEEbRNSI_6vectorINS4_16TrackMeasurementENSI_9allocatorISQ_EEEERNSP_INS4_26TrackToLandmarkAssociationENSR_ISV_EEEERNSP_INS4_18RelativeAnchorDataENSR_ISZ_EEEERNSP_INS4_7TrackIdE 08-21 07:55:41.448 5662 5662 F DEBUG : #10 pc 00000000009dbbfc /system/lib64/libMontereyTracker.so (_ZN5viper7Tracker5trackERKN4TooN3SE3IdEERKN10perception8OptionalINS1_6VectorILi3EdNS1_8Internal5VBaseEEEEERKNS_11VideoFramesEPKNS_15ImuMeasurementsERKN5boost8optionalINS1_3SO3IdEEEERKNSM_INS8_ILi3EfSA_EEEE+2756) 08-21 07:55:41.448 5662 5662 F DEBUG : #11 pc 0000000000987268 /system/lib64/libMontereyTracker.so (_ZN5viper4Slam4Impl9track_mapERKNS_11VideoFramesEPKNS_15ImuMeasurementsERKN5boost8optionalIN4TooN3SO3IdEEEERKNS9_INSA_6VectorILi3EfNSA_8Internal5VBaseEEEEE+268) 08-21 07:55:41.448 5662 5662 F DEBUG : #12 pc 0000000000976608 /system/lib64/libMontereyTracker.so (_ZN5viper4Slam4Impl14process_framesERKNS_11VideoFramesE+332) 08-21 07:55:41.448 5662 5662 F DEBUG : #13 pc 0000000000992d9c /system/lib64/libMontereyTracker.so (_ZN5viper18VideoFrameAnalyzer4Impl14process_framesERKNS_11VideoFramesE+372) 08-21 07:55:41.448 5662 5662 F DEBUG : #14 pc 000000000098ff4c /system/lib64/libMontereyTracker.so (_ZN5viper18VideoFrameAnalyzer4Impl9on_framesEN10perception6IdTmplItNS2_8vio_toon13FrameSetIdTagELb1EEEN3gsl4spanIKPKhLln1EEENS_13LiveTimestampENS8_IKdLln1EEESF_+1188) 08-21 07:55:41.448 5662 5662 F DEBUG : #15 pc 00000000008e1904 /system/lib64/libMontereyTracker.so (_ZN8coretech23InsideOutTrackingEngine11onImageDataEPK9ImageDatai30ProcessingClockDomainTimestamp+768) 08-21 07:55:41.448 5662 5662 F DEBUG : #16 pc 000000000111b20c /system/lib64/libMontereyTracker.so 08-21 07:55:41.448 5662 5662 F DEBUG : #17 pc 0000000000020a4c /system/vendor/lib64/libdevices.so (_ZN3OVR7Devices21CameraFrameSetManager12sendFrameSetERNSt3__16vectorINS2_10shared_ptrI9ImageDataEENS2_9allocatorIS6_EEEE+560) 08-21 07:55:41.448 5662 5662 F DEBUG : #18 pc 0000000000020c44 /system/vendor/lib64/libdevices.so (_ZN3OVR7Devices21CameraFrameSetManager23processCompleteFrameSetERNS1_8FrameSetERNSt3__16vectorINS4_10shared_ptrI9ImageDataEENS4_9allocatorIS8_EEEERNS4_11unique_lockINS4_5mutexEEE+80) 08-21 07:55:41.448 5662 5662 F DEBUG : #19 pc 000000000001fba4 /system/vendor/lib64/libdevices.so (_ZN3OVR7Devices21CameraFrameSetManager20frameSetOutputWorkerEv+212) 08-21 07:55:41.448 5662 5662 F DEBUG : #20 pc 0000000000020e8c /system/vendor/lib64/libdevices.so (_ZNSt3__114__thread_proxyINS_5tupleIJMN3OVR7Devices21CameraFrameSetManagerEFvvEPS4_EEEEEPvS9_+116) 08-21 07:55:41.448 5662 5662 F DEBUG : #21 pc 0000000000075da8 /system/lib64/libc.so (_ZL15__pthread_startPv+204) 08-21 07:55:41.448 5662 5662 F DEBUG : #22 pc 000000000001e1c4 /system/lib64/libc.so (__start_thread+16)1.8KViews2likes2CommentsWhere is my RAM? Unity app on Oculus GO non-deterministic crashing with < 1gb memory used!
Been at this for a couple weeks now, so I need help. I have a relatively large app with many features, and recently it started exhibiting crashes, mainly during a new scene load, which made it terrible to track down. I eventually figured out were due to out-of-memory issues. I had no logs saying this, but doing an adb bugreport eventually showed the culprit as lowmemorykiller ending the process abruptly. So using Unity's great profiling tools, I was able to get my RAM consumption down from about 2gb to under 1gb. Crashes seemingly abated. Then I went on with other optimizations, including switching from GLES2 to GLES3+Single Pass Rendering. Now the crashes are coming back! I'm not using any more memory, except possibly for GLES3 itself - the profiler shows 1.02gb in use, 0.76 for unity and 270mb for "GfxDriver". However, I was previously able to have 2gb in memory before crashes before, on GLES2, so why would I crash now at ~1gb on GLES3? Further, the crashes are not consistent - sometimes I can play everything fine with no crashes, other times not. Sometimes, simply connecting to the Unity profiler pushes me over the edge to a crash, further complicating my debugging process. If I'm interpreting things correctly, the profiler says (right before the crash) that I'm using 1.02gb out of "reserved" 1.05gb, and that 2.40gb "total system memory usage" - so what is using the extra 1.4gb? Is there any better way I can isolate the specific causes of the issue? I really can't do much more to manage my RAM usage. Half of it is out of my control - 270mb on the graphics driver, and 200mb for the eye render textures - and it just feels like every time I lower my memory usage a bit, the point where I get a crash becomes lower to compensate. If I can't get an answer I'll just have to go back to the inexplicably working GLES2, and lose single-pass rendering, but that will lead to degraded user experience, so please send any suggestions! Thanks2.3KViews2likes4CommentsUnity App Crashing on Quest
After building our metaverse application and not having tested in a while, it seems to not be running and instead crashing on each launch. Oculus firmware 50 seems to be the cause of this. We are using 2021.3 LTS and IL2CPP with Arm64. The error is a Sigabrt Signal 6 Code -1 Fatal Exception Java Lang Error. The app seems to be working with Mono Arm7 but only when it doesn't have more than like 4 scenes. I hear that firmware 50 may have Android 12 and was released for early access users. We've tried everything in the book to fix this, and apparently the performance isn't going to be the same either even if we do get it to run. We are going to update to Unity 2022 to see if this fixes anything but we've been spinning our wheels like crazy. Please let me know if you have any ideas as to why it is suddenly crashing without explanation.Solved11KViews2likes10CommentsUnity editor crash with openXR on startup
I'm using Oculus SDK inside Unity and whenever I try to run Unity with no headset attached it crashes. I've opened a bug report with full logs given to them and they've concluded that the problem was the oculus sdk. They send me this saying this is the cause of problem : 0x00007fff76fd6ad7 (LibOVRRT64_1) ovr_ReleaseHapticsClip 0x00007fff76f9e902 (LibOVRRT64_1) ovr_ReleaseHapticsClip 0x00007fff66610876 (OVRPlugin) ovrp_UnityOpenXR_OnSessionDestroy2.2KViews2likes2CommentsOculus + Air Link causes computer crashes when the headset disconnects from WiFi.
As usual, it's hard to pinpoint exactly where the issue originates due to all the handoffs between apps. My Quest 2 is connected via Air Link through the Oculus App, to SteamVR, which is then running VR in Unreal's editor. If the connection is active and the headset is awake, I can successfully run in editor as many times as I want. If the connection is not active (only SteamVR is open, Oculus is closed and not set up), Unreal will successfully fall back to a spectator pawn. If the connection is active but the headset has disconnected, my computer will freak out and eventually crash whenever I interact with VR. So far, those crash events occur when I open Unreal (which presumably makes contact with the VR setup) and when I hit that Play in VR button in the editor (as when the headset's fallen asleep between uses). As soon as one of these actions is initiated, I hear cable whine from my PC--the only time I've found that it does this--and I have a very short time to catch it before the mouse freezes, the screen stops, and the computer needs to be restarted. If I'm able to get my headset on, dismiss the lost connection dialogue, and reconnect to my PC over Air Link, it has a decent chance at recovering. I think I've had this happen with Unreal closed, though the above is my primary observations so far. SteamVR has been opening and closing for ages and never caused this on my computer. I previously used VirtualDesktop for this and also never had issues there, though this was largely before my current PC was built so that's not a clear indicator. The computer itself is very new and, on paper, shouldn't be a problem. GPU - 3080 Ti CPU - 5950x RAM - 64gb2.3KViews1like1Comment