2

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!!

UPDATE 1

I checked that the currentFrame is still valid when calling the hitTest. Despite checking this with if(_arsnView.session.currentFrame), the app still shows the same crash :(

cujo30227
  • 720
  • 7
  • 15
  • There are two inputs to the function you’re testing, so if you’ve eliminated one of them (position) as the possible cause, it’s time to check the other: the entire current state of the `ARSCNView` and its AR session. That sounds scary, but actually there aren’t that many cases to test if you reason about which could be possible causes. Are you hit testing before the session initializes? Or during relocalization? Is the session actually running when you try to hit test? And so on. – rickster Apr 06 '18 at 16:38
  • Also, it might be worth opening a [bug report](http://bugreport.apple.com) with the crash analytics data you have, even if you can’t reproduce the crash yourself (yet). – rickster Apr 06 '18 at 16:38
  • Are you waiting until the ARSession has initialized before you are attempting to perform a hit test? The extrinsicTransform is a property of the camera, and it could be initialized to a value that's not valid until the session has initialized. – ACVM Apr 06 '18 at 21:54
  • Thanks for the feedback. The hitTest method is only called from the ARSession delegate method - (void)session:(ARSession *)session didUpdateFrame:(ARFrame *)frame > so the session must be active. However, I do pause the session at some points in the code. Perhaps this is the trigger and I need to check for a valid currentFrame before applying the method? if (!self.session.currentFrame) return;. Will post the results – cujo30227 Apr 06 '18 at 22:37
  • Thanks for your help. I found that checking whether the session's current frame is valid, does not prevent the crash from occurring. I updated the question to add this new info.. – cujo30227 Apr 08 '18 at 21:58
  • Check the tracking state too. Hit testing doesn’t work during initializing or some of the limited states. – rickster Apr 09 '18 at 04:40
  • I am facing a similar issue with my app. Since I am using separate threads for related items, I am investigating it from that pov. Let me know if and when you are able to resolve this. – Manganese Apr 09 '18 at 16:27
  • 1
    Ok, will do. I'm now checking the trackingState before calling hitTest. Will let you know whether that resolves the crash. – cujo30227 Apr 10 '18 at 05:35
  • I have received a crash log from Apple, the file is 20MB, adding snippets below, let me know if you need other things, since the file contains multiple thread information and is thousand of lines long. Now 75% of my users are affected and I am pulling my hairs out debugging this. – Manganese Apr 11 '18 at 11:37
  • Do you have any other Non ARHitTest methods called in your renderer loop ? I was hit testing for nodes (not AR anchors), using the [SCNHitTestOption.firstFoundOnly:true]. This caused a BAD_EXC crash, fixed it by using [SCNHitTestOption.boundingBoxOnly:true]. I noticed that the crash might be happening when ARKit updates an existing plane anchor while hit testing. – Adrien Yvon Apr 11 '18 at 14:26
  • I have added the response received after raising TSI to Apple. Hope it helps. – Manganese Apr 11 '18 at 18:48

3 Answers3

2

Thanks for your help. I found that checking the trackingState before performing the hitTest, resolves the crash. So basically, I'm checking:

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

In this example, _arsnView is a property from class ARSCNView

cujo30227
  • 720
  • 7
  • 15
1

Anyone log a bug for this for 11.3? Getting the same effect trying to test an application with 11.3 on an iPhone X

Tyler Hackbart
  • 1,948
  • 1
  • 10
  • 5
  • I received a crash log from Apple, since it crashed when they were reviewing it, but it's a heavy file: – Manganese Apr 11 '18 at 10:59
0

My apologies for the earlier one, last night I was too sleep deprived.

Anyway, I raised a TSI for Apple, and they came back with the following. 

Thank you for contacting Apple Developer Technical Support (DTS).

This a known issue 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 workaround is simply to not hit test when in either of those tracking states. This is also a best practice.

I hope this information suffices to address your concern to your satisfaction.
Manganese
  • 650
  • 5
  • 26
  • Hi, not clear how this is related to the question. The crash report is not from an device running on iOS11.3, and there are no signs that this is related to ARKit. – cujo30227 Apr 11 '18 at 13:54
  • 1
    That's his whole point, when the ARCamera (https://developer.apple.com/documentation/arkit/arcamera?changes=latest_minor&language=objc) reports a TrackingState that is NotAvailable or Limited, then you should not perform a hitTest. In the comments above, that's what I was alluding to. You need to listen for this state as well as the frame state. – ACVM Apr 11 '18 at 22:34