Since upgrading to AR-Foundation 4.2.8 from 4.2.3 this issue has affected 155 users, logs indicate they were closing the AR scene. We Destroy all items in AR-planes.trackables, then call reset on the AR session before Async unloading the scene.
Details:
Unity version 2021.3.9f1
ARFoundation version 4.2.8
ARCore XR Plugin version 4.2.8
Affected 155 users in last 7 days.
Affected 80% Samsung devices.
Affected 78% Android 13
A simplified Stack trace: #01 Firebase.App.cpp:? (Not clear if this is important) #02 NativeApi_UnityARCore_session_reset_m #03 Unity.XR.ARCore.cpp:? #04 2tvs_utils0.lump.cpp:? #05 ARCoreProvider_Reset_m #06 ARSession_Reset_m #07 UnityEngine.UIElementsModule7.cpp:? #08 UnityEngine.UIElementsModule7.cpp:? #09 SC_AR_CloseAR_m (Our close function attached to a UI button)
Trackable components and their GameObjects are managed by their ARTrackableManager, and correlate to data that is managed by ARCore itself. Our API is designed to always respect the platform’s representation of AR data, and you can introduce errors by manually destroying trackables.
That’s the top of your crash callstack; it seems extremely important
“Firebase” is a Google SDK. Do you have the source to, or know where in, Firebase.App.cpp you are crashing? What is the crash reason, e.g., null pointer? jump to address 0x0?
Hi Andy, Before closing our AR scene we loop through all the Trackable planes and delete them, we used to have an issue with un-interactive planes remaining in the scene if the user reloaded into the AR scene. We have removed this loop and just call .Reset() on the ArSession, this appears to be functional in testing, so we will push this change to production and see if this remedies the crash. Thanks for your feedback.
@mekin I’m sure its important, but I was wondering if its the top of the stack because Firebase Crashlytics caught and reported the crash. As for the specific error, there is no detailed info in the crash, SIGSEGV title and an un-symbolicated stack, I used address-2-line and my symbols file to get the stack trace above. I don’t know why we no longer get a proper crash and tombstone text file
I just observe the exact same crash fyi. It didn’t use to crash in old ARfoundation version 4.2.7, but any version after crashes after arsession.reset()
I will definitely file a bug but whats the best workaround for now to reset arsession? (Whenenabling and disabling it to enter and exit AR)
In the meantime you should avoid calling ARSession.Reset while the session is initializing. This is not a good practice, as there is no data to reset. The session isn’t even initialized yet. But we will fix our plug-in so it doesn’t crash :).
Thank you for the suggestion, I was experiencing the same issue and checking for the session state before resetting did the trick! Thank you @andyb-unity !