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.
Related
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.
I'm at a complete loss with a memory bug. This issue only happens on the device and not the simulator. It also only happens when the app is loaded for the first time on the device. If I close the app and relaunch it the issue does not preset itself. This is the error I'm getting
-[CFString retain]: message sent to deallocated instance 0xfd5a2f0
I've tried everything to attempt to figure out what the released string is. Please help me figure out what the released object is when running on the device and not the simulator! Thanks in advance!
UPDATE:
I still do not have a solution but I have confirmed the app will crash consistently on the line of code where I set a frame and the above error shows. If I comment this code out the app will pass this point but may crash at other strange spots. I can't even begin to determine where the crash is originating.
CGRect frame = CGRectMake(27, 96, 265.0, 50.0);
someAcct.frame = frame;
I'm so confused by this since this is not a string. Any ideas?
UPDATE 2: This issue is directly related to the NSUser Defaults being synchronized. This seems pretty random but this is causing the issue. Any Help?
UPDATE 3: The problem has been solved as of a week ago. This was in fact due to a string being inaccessible. A string was passed to a method, that method then did work and passed data to another method and so on. Until finally the data was to be written to user defaults and a local plist contained within the documents folder. All of a sudden the app would crash at very strange places like the above consistently even though those places had nothing to do with a string. I was baffled and after playing with it for a very long time I decided to head over to the .h file and go through each string one at a time by making sure each were synthesized in the .m file and that self.stringName was applied throughout the .m file. After spending an hour on this I finally found the string that was to blame and the issue is now resolved. Using self.stringName allows the memory to be found and avoids these obscure and highly confusing application crashes. Thanks to everyone for all of the suggestions and tips!
To help you with tracing it down, could you try putting NSLog at the start of your didFinishLaunching() method, somewhere in the middle and at the of the didFinishLaunching().
Then also could you push a NSLog in the viewDidLoad() of the first view controller your app shows. For example, if you're using a tab bar interface, then a NSLog in the first tab's root view controller.
You can use NSLog(#"step 1"), NSLog(#"step 2"), NSLog(#"step 3") ... to organise the output so you know where the code managed to reach up to before it crash, rather than NSLog(#"I am here").
The problem is of retain count. Refer mememory management and check u r not missing something.
Don't forget to turn on NSZombieEnabled.
One reason can be due to the iOS compatibility.Check if your device and the simulator are using the same iOS.Try working the simulator on the same version of OS as your device and change the release of the string accordingly.
I pressed alt+cmd+r and activated NSZombieEnabled in Arguments > Environment Variables. Additionally, I activated it in Diagnostics > Memory Management > Enable Zombie Objects.
However, when I built and run, at some point my app crashes giving me this useless message in the console:
*** -[CALayer retainCount]: message sent to deallocated instance 0x656b260
The stack trace is just as useless. I moved the details-level slider all the way to the right. Thread 1 simply shows me this:
Everything is system-owned and there's not a single line related to my app. So obviously NSZombiesEnabled doesn't work as it did in Xcode 3, where it halted on the dead object.
Is there any way to figure out which CALayer is deallocated too early?
Update: So after building and running about 100 more times suddenly the problem DISAPPEARED! It's completely gone! And the best part: I did not modify my code in any way! Inbetween I cleaned the build folder and project with the clean commands several times and deleted the app in the Simulator several times as well.
Update 2: Fortunately the problem re-appeared. And now it seems persistent. Fortunately, because I prefer finding the root cause rather than annoying the users by random.
Update 3: Finally found it by accident:
startButton = newBttn;
should have been:
self.startButton = newBttn;
startButton was a retaining property and in -dealloc I released it. So it got overreleased and in most (but not all) cases after the view faded out it crashed giving that weird CALayer retainCount message.
The Zombies Instrument (CMD + I) finally pointed out that it had to do with a button. Just didn't know why and where.
Clang Static Analyzer didn't complain about this obvious glitch.
If this crops up again, you can run a dedicated Zombies instrument. Hit Command+I to profile the app and select the Zombies instrument (you must be running on the simulator). If you get a zombie, you can display the entire memory history (each retain/release) for that object, which is immensely helpful in tracking down errors.
In addition to Jeff's great answer; to do almost the same thing, but without having to open Instruments or profile your App, you can 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.
This article has some additional info.
we have an iPhone app in the app store where we see a lot of crashes after an update. These crashes did not occure when testing it before submiting it to the app store and we cannot reproduce the crash on our own devices.
Heres the crash message we get:
'NSInvalidArgumentException', reason: '*** -[MessageHeader ]:unrecognized selector sent to instance 0x4551450'
The source that causes this message is:
[self fireDelegateIfRegisteredMessageId:header.messageID andMessage:message];
The only place where MessageHeader is referenced is "header.messageID" but I am wondering how this selector would become nil. Also that same statement is used on various places above this line and it worked there.
What could cause this problem? Espacility what could cause an selector to become nil except the following code?
SEL selectorTest = nil;
[self performSelector:selectorTest]
I had a similar problem. My problem was a buffer overflow shortly before the line who caused the exception. It was some quick and dirt feature adding and forgot to check it thoroughly.
I used to write 16 Bytes in a 8 Bytes big buffer. The exception uccured only on device and not in simulator or debug builds. It was really an anoying bug.
I have a working program that was written by another programer that I am trying to add some features to in an effort to learn the iPhone SDK. I have carried out what I would assume was a fairly simple task of adding an additional UIButton to an existing view with like buttons. I have used the other UIButtons as a model and it seems this should be a simple task.
The problem is when the line that calls this subview is executed I get the rather vague error flag of TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION. Where do I find more information on this error code? I looks to me like a very general error and certianly there must be someplace in the Xcode shell that gives me more detail on what this means?
I have isolated the line where it occurs and it seems to happen on the first reference to the new view. Is it a problem with the connections made in interface builder? Any suggestions would be helpful as I really feel like I am grasping at straws at this point...
You want want to trap the exception when it happens, you might then be able to track it down in the debugger. A useful set of breakpoints to use when your debugging Cocoa apps are objc_exception_throw and -[NSException raise]. In the iPhone I think all exceptions travel through objc_exception_throw but if your were targetting Tiger or earlier you should set a breakpoint on both.
There are more debugging techniques at http://www.cocoadev.com/index.pl?DebuggingTechniques.
This is an exception generated by the Objective-C runtime. Hit CMD-SHIFT-R to bring up the debugger console. You'll see all the gdb startup information at the bottom of the window, but if you scroll up past the stack info, you'll get to something that should look like this:
[Session started at 2009-04-09 14:39:27 -0700.]
2009-04-09 14:39:31.246 LearnGLES[10415:20b] *** -[EAGLContext fakeMessage]: unrecognized selector sent to instance 0x528150
2009-04-09 14:39:31.248 LearnGLES[10415:20b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[EAGLContext fakeMessage]: unrecognized selector sent to instance 0x528150'
2009-04-09 14:39:31.250 LearnGLES[10415:20b] Stack: (
2517758219,
2486509115,
....
That's just a complete sample exception that I made up by changing code to send a non-existent message to an object, but there are a lot of possibilities as to what yours might be. Anything that would generate a run-time exception in any of the Objective-C frameworks could be the culprit (un-parseable dates to a date formatter, invalid messages to objects, etc...)
It probably means that you used some memory after deallocating it or used it without initializing it. Often when you look at the stack after this all you'll see is the part of the main loop that performs the autoreleases, which clearly isn't going to help you.
Really you need to get a good understanding of how memory management works in Objective-C and then take a look at your changes. There's not really a silver bullet here. The good news is that it gets easier with experience.
This is a nice article about debugging in Objective-C.
What connections have you made in interface builder? Are you making a call to any methods when the button is clicked? What is the method signature in that case? Have you made any changes to the original code, where you might have accidentally deleted some code which was important. It would help if you post some code. The exception is very generic.
I had a similar problem when I released things that I had not explicitly allocated.
In my case, I had a background image UIImage *image=[UIImage ...] and was setting it to be the background of my UIButton, and then did [image release];
You don't want to do the [image release]: the UIButton owns it now, and it will free it when no longer needed.
Maybe you have a similar issue?