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 :(
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
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
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.
Related
Disclaimer: I'm helping out on another developer's code (he didn't have the time and the customer wants it fixed quickly) and so I'm not totally familiar with this code.
So the app is built for iOS 6, is in the App Store, and runs great. Until you try opening it on a device running iOS 7 GM. You see the splash-screen for a moment, then it crashes completely. This is causing problems because none of our users can use the app anymore after updating.
I just got the source code and I have been trying to figure it out. It compiles fine, and even runs in the iOS 7 simulator. (Although, of course, the UI needs to be redesigned for iOS 7.)
Here's where it gets weird: when I run it on my iPhone 5 (iOS 7) from Xcode, the app hangs (just like with the App Store version, of course) -- but it's just so weird, considering that in runs in the Simulator.
Good news is that I have some runtime errors that might help to track down the problem. I ran a search that indicates it could be a missing connection in a xib file, but I didn't find one.
Here is the log. If it helps, I can also include the build warnings.
2013-09-20 20:16:55.455 myappname[2514:60b] * Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan nan]'
* First throw call stack:
(0x2e3d0e8b 0x386ca6c7 0x2e3d0dcd 0x307d5feb 0x307d5eef 0x307d5e7f 0x30b53517 0x30b6373b 0x30c042f1 0x30b56533 0x307ddf43 0x307d9767 0x30b6b411 0x30b67ed5 0x30be7501 0x30be71a1 0x30c03685 0x30bcf53d 0x30c034bf 0x30b55f3d 0x30b55d19 0x30b55609 0x2ed32143 0x30b55495 0x30b62153 0x30b61bd3 0x30c43e13 0x30c8398b 0x30c83961 0x30c82abf 0x30c82663 0x30c8256f 0x5c4d7 0x30bc7425 0x30bc6e6b 0x30bc14b9 0x30b5bbe7 0x30b5aedd 0x30bc0ca1 0x3303c76d 0x3303c357 0x2e39b77f 0x2e39b71b 0x2e399ee7 0x2e304541 0x2e304323 0x30bbff43 0x30bbb1e5 0x5b485 0x38bc3ab7)
libc++abi.dylib: terminating with uncaught exception of type NSException
Thread 1: signal SIGABRT
I really have no idea what is going on.
Any help would be greatly appreciated :)
try to use preferredContentSize to define view size.
I'm facing unexpected crashes of my app running on an iPhone 4 with iOS 5.0.1, the app crash without generating any error message nor crash log. I did also enabled zombies and tested with Instruments with no luck... how can I figure out where is the problem? I'm totally stuck :(
ps. I'm using ARC and my app is multi thread (NSOpertations + GCD)
(By popular demand:) There are some hints for catching the failure in this thread.
From the breakpoint-menu in Xcode, press the little '+' button at your window bottom left, and add an exception breakpoint. It will give you a heads up if the app throws an exception due to erroneous code.
Just follow this url you will get trick to track the causes of crash.
add some breakpoint before crashing point and add a lot of NSAssert to check your assertion.
A crash was reported in my app, Crash Pad Drums.
It cites a problem with certain cymbal sounds causing a crash on an iPod 4. One problem. I can't find the crash on my iPod touch 2, and I don't have an iTouch 4.
What in the heck can I do about this?
On another note, my app is free for today. If someone could download it and find the circumstances of the crash, I'd be in your debt.
EDIT:
Clarification
I can't actually cause the crash as I don't have a newer device to test on. I suspect that it's an iOS 5 issue which I am looking into now, but in the future what should I do if I'm cheapo and not willing to buy a new iTouch?
EDIT:
Console log:
2011-10-14 23:08:25.797 Crash Pad[794:12203] -[NSConcreteValue doubleValue]: unrecognized selector sent to instance 0xec9e2e0
2011-10-14 23:08:25.798 Crash Pad[794:12203] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSConcreteValue doubleValue]: unrecognized selector sent to instance 0xec9e2e0'
*** First throw call stack:
(0x1c49052 0x21fdd0a 0x1c4aced 0x1baff00 0x1bafce2 0x16f4f0 0x15d99e 0x14e0d8 0x168d42 0x15ace2 0x5c28c7 0x5c2a31 0x5c2d45 0x1be0f4a 0x1bac665 0x1bac056 0x5c2c43 0x249c8 0x24a58 0x8a72 0x1c4aec9 0x67a299 0x67a306 0x1c4aec9 0x67a299 0x67a306 0x5b6a30 0x5b6c56 0x59d384 0x590aa9 0x28c3fa9 0x1c1d1c5 0x1b82022 0x1b8090a 0x1b7fdb4 0x1b7fccb 0x28c2879 0x28c293e 0x58ea9b 0x1f0d 0x1e85)
terminate called throwing an exceptionCurrent language: auto; currently objective-c
What you've found is an Apple bug. You can easily reproduce by animating any view, like this:
CABasicAnimation *anim = [CABasicAnimation animationWithKeyPath:#"transform.scale"];
anim.duration = 0.2;
anim.repeatDuration = HUGE_VALF;
anim.autoreverses = YES;
anim.toValue = [NSValue valueWithCATransform3D:CATransform3DMakeScale(0.9, 0.9, 0.0)];
[view.layer addAnimation:anim forKey:#"throb"]; // if this isn't nil we crash on tap
Run the project. Tap the throbbing view. Crash. This code was perfectly fine on iOS 3 and iOS 4. The workaround for now is to set forKey: to nil, but that may be unacceptable, as this argument can be important - a non-nil key means that if you later add another animation with the same key, this animation is removed, which might be exactly what you were trying to do.
I have submitted a bug report to Apple, and I suggest you do the same.
EDIT (2/3/12): Okay, Apple says this is my bug, not theirs. Since I'm supplying a transform, I need to use a key of #"transform", not #"transform.scale". Moreover, the z-value of my 3D scale transform should be 1, not 0.
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. Then, when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
Do you have a crash log or two that you can post? That would be helpful.
Given that it is crashing on newer hardware as opposed to older, it is unlikely to be a memory related issue. Most likely, it is a timing issue related to threading; the faster device gets something done sooner and touches a data structure before something else is done with it. Given that sound playback is a constant duration across the different devices would lend further credence to this theory.
It ended up being an issue with iOS 5. I was able to narrow down the cause of the crash by commenting out various pieces of code. When in doubt, comment out.
I have some code that returns a struct containing 2 objects (declared as id).
When trying to use one of the objects I get an EXC_BAD_ACCESS and the app crashes. This only happens on the device (ipad) not in the simulator.
I have set NSZombieEnabled to YES, however no information is written to the console.
I don't know if it's a problem that I'm using a workspace in Xcode 4, one project for my app, and another that builds a library which is used in my app. The EXC_BAD_ACCESS is occurring in the second project, so I don't know if NSZombieEnabled will apply to the second project?
How do I solve this? Especially as I it only happens on the device (even goes as planned on the simulator), and it is in the second project?
EDIT: This is the method where the EXC_BAD_ACCESS occurs, on line 62, on sortRange.lower –
NSZombieEnabled only works on the simulator, not on the device, so it's probably hiding the problem. Run Product > Analyze (⇧⌘B) for clues. It's harder to say more without looking at the code. As Mihai says, your objects are probably over released, which is the most common cause of EXC_BAD_ACCESS.
It seems that one of your objects is autoreleased before you are trying to access it. As the iPad has less memory than the computer you are running it on it get's released faster so that's why it's not available. Try NSLog both objects just before the line you are getting the error and see wich one of them is the problem and than trace back to it's origin and retain it somehow. Also don't forget to release it after you are done using it. Some example code would be useful.
I have a memory leak, so i tried to debug with nszombie....
And NSZombie printed this:
-[MobileOfferViewController _shouldUseKeyWindowStack]: message sent to deallocated instance 0x6307580
So my question: what is the method: shouldUseKeyWindowStack??
Found nothing on Google....
Thanks,
Martin
I fought with a similar error for quite some time. Best I can tell, _shouldUseKeyWindowStack is an internal UIResponder method that showed up in iOS 4.0 (I assume related to multitasking somehow).
However, the real error with this type of thing is usually a memory access error (too many releases on an object, or a threading error). In my case, it was a threading error - specifically, trying to update the UI (show a UIAlert) in a background thread. I ended up wrapping the code that was causing the crash in it's own method and then calling [self performSelectorOnMainThread:withObject:waitUntilDone:] to work around the crash.