ARKit crashing in iOS11.3

Question

cujo30227 OP

Created Apr ’18

Replies 3

Boosts 0

Views 2.5k

Participants 3

Hi,

Since iOS11.3 I'm getting a significant number of new crash reports from my AR measurement app.

The crash description says:

Exception Type: SIGABRT

Exception Codes: #0 at 0x181b112ec

Crashed Thread: 0

Application Specific Information: *** Terminating app due to uncaught exception 'std::invalid_argument', reason: 'extrinsicTransform must have determinant 1.'

The crash is triggered by this line in my code, which is called on didUpdateFrame

NSArray<ARHitTestResult *> *resultArray = [_arsnView hitTest:position types:ARHitTestResultTypeExistingPlaneUsingExtent | ARHitTestResultTypeEstimatedHorizontalPlane];

According to the crash reporting, it happens to about 10% of the sessions (!!!!). Before iOS11.3, I had <0.1% crashes.

I tried feeding the hitTest with different values for position, including NaN etc, but I'm not able to reproduce the crash.

Any ideas?

Thanks!!

Answered by cujo30227 in 305127022

Yes, it is indeed related to the trackingState. I can confirm that the crash is gone when first performing a check on the trackingState, e.g.:

    if (_arsnView.session.currentFrame.camera.trackingState!=ARTrackingStateNormal)
    {
         // do not perform hitTest
    }
    else
    {
         // perform hitTest
    }

In this example, _arsnView is a property from class ARSCNView

Boost

Answer 1

philh OP

Apr ’18

We are also seeing:

*** Terminating app due to uncaught exception 'std::invalid_argument', reason: 'extrinsicTransform must have determinant 1.'

in our app as well, and only with iOS 11.3.

0

Answer 2

OP

Apple

Apr ’18

This looks like a symptom of hit testing when the tracking state is bad.

This can occur when you perform a hit test and the ARCamera’s tracking state is either .notAvailable or .limited.

https://developer.apple.com/documentation/arkit/arcamera.trackingstate

The best practice is to simply not hit test when in either of those tracking states.

0

Answer 3

cujo30227 OP

Apr ’18

Accepted Answer

Yes, it is indeed related to the trackingState. I can confirm that the crash is gone when first performing a check on the trackingState, e.g.:

    if (_arsnView.session.currentFrame.camera.trackingState!=ARTrackingStateNormal)
    {
         // do not perform hitTest
    }
    else
    {
         // perform hitTest
    }

In this example, _arsnView is a property from class ARSCNView

0