I'm a Project Manager trying to help out with my developers;
We had a build that was ready for submission; crash free and testing was done on an iPad. The following day when we began testing it on iPod and iPhone 3G, we noticed a boatload of crashes. We reinstalled the build on the iPad and low and behold a boatload of crashes showed there too.
We noticed that when you reboot the device and reinstalled the app, crashes didn’t seem to happen at all, everything would look ok for the first couple of minutes and then you get a crash. Oddly enough, the app crashes easily afterwards.
Crashes happen mostly on one specific screen of the application, the crashes doesn’t seem to be specific to an action that we can tell. We are connecting to a third party API to populate data in the screen and we are using Restkit. Crashes sometimes appear to originate from Restkit. Below is an example of an error log we got:
0 libobjc.A.dylib 0x34f70ca4 objc_msgSend + 28
1 CoreFoundation 0x325ae0b8 __CFBasicHashStandardRetainValue + 8
2 CoreFoundation 0x325abb30 __CFBasicHashReplaceValue + 44
3 CoreFoundation 0x32505f98 CFDictionarySetValue + 68
4 CoreFoundation 0x3250c94e -[__NSCFDictionary setObject:forKey:] + 54
5 Foundation 0x34d8a31a -[NSMutableDictionary(NSKeyValueCoding) setValue:forKey:] + 10
6 nameofapp 0x000ae958 -[RKClient setValue:forHTTPHeaderField:] (RKClient.m:173)
7 nameofapp 0x000086ae -[WebServer addCustomHeaders:] (WebServer.m:140)
8 nameofapp 0x000088ea -[WebServer getDoD:objectTarget:] (WebServer.m:197)
and
WebServer.m:140 [[objectManager client] setValue:#"text/json"
forHTTPHeaderField:#"X-ZFWS-Accept"];
Two things - First, we need more information. What's the rest of that crash log say? Second, and equally important, if you're running RestKit (or anything else for that matter) on an iPhone 3G then you must make absolutely certain that "Compile for Thumb" is turned off for the ARMv6 architecture. I noticed that a lot of my various mysterious crashes went away simply by ensuring that "Compile for Thumb" is turned on for ARMv7, but off for ARMv6. The iPhone 3G (and possibly your iPod) uses the ARMv6 architecture which does not have Thumb support. When Thumb is turned on for the v6, there's no telling how it's going to work (or not) because the chip is getting bad instructions. However, don't simply turn off Thumb, because you get a big speed bump on newer devices like the iPhone 4 and the iPad.
In your Xcode projects, open up your build settings and click on the title for "Compile for Thumb" then select from the gear menu down the option to "Add Build Setting Condition". Change the "Any SDK" to "Any iOS" and change "Any Architecture" to "ARMv6", then make sure the "Value" is unchecked. Now do the same thing, creating another Build Condition for ARMv7, and select/check the Value to be on.
In the RestKit library, you may have to do this for each of the various targets that it has.
Related
I've read numerous threads on stackoverflow and on apple site and I still cannot get basics to work. I make a debug build of my app, I install it on my phone, this build intentionally crashes. I run this app while not connected with Xcode debugger. The app crashes, how do I see now function names and line numbers of the crash backtrace?
I tried to open devices windows in Xcode and there Iviewed the log, I see my app crashlog, I see that there were multiple function calls in my code before it crashed, but all of them are shown as hex addresses and not actually symbolicated. What do I need to do to make it work?
Open Project Settings. Go to your Target and set the Debug Information Format to DWARF with dSYM File for Debug. Do the same for the Project
Project:
Target:
Xcode will symbolicate the crash report, which can take a few seconds, only if you still have the matching symbols of the build that triggered the crash. If the symbol exists simply wait a bit and the crash report will update.
If you in the meantime changed some code and triggered a new build, then the build and symbol files will be overwritten and get a new UUID (per CPU architecture). That UUID is part of the crash report (Binary Images section) and used to find the matching symbol file on your Mac. If that isn't found, then symbolication can not work.
Could it be you are using an invalid character in your project name?
I had this same problem with seeing the hex and not the actual function names. Turns out the issue was a unicode character in my Apps name "➕". I removed it and then the subsequent crash logs in xcode would show the function calls correctly.
Any solution for this. I am having exactly this problem. I build, run it on my iPad, stop execution, and then manually start the app on the iPad. It crashes, I go to the Device Logs, and the crash is there but it won't symbolicate:
0 CoreFoundation 0x1b0d035ac __exceptionPreprocess + 220
1 libobjc.A.dylib 0x1c4d7d42c objc_exception_throw + 59
2 CoreFoundation 0x1b0c0c1b4 +[NSException raise:format:arguments:] + 99
3 Foundation 0x1b1f6a7bc -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 131
4 xxxxxxxxxxxxxxx 0x102f6c2d4 0x102f64000 + 33492
5 xxxxxxxxxxxxxxx 0x102f6c23c 0x102f64000 + 33340
6 xxxxxxxxxxxxxxx 0x102f76754 0x102f64000 + 75604
7 xxxxxxxxxxxxxxx 0x102f764ac 0x102f64000 + 74924
8 xxxxxxxxxxxxxxx 0x102f76f40 0x102f64000 + 77632
9 xxxxxxxxxxxxxxx 0x102f83fa0 0x102f64000 + 130976
There are no Unicode characters in my app name (which isn't really xxxxxxx).
I've been coding my typical random stuff in Objective-C/iOS for some years.
Today, a customer I'm dealing with came up with this apparently innocent Crashlytics crash:
Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x193b0e1c0 \__exceptionPreprocess
1 libobjc.A.dylib 0x19254855c objc_exception_throw
2 CoreFoundation 0x193b15278 \__methodDescriptionForSelector
3 CoreFoundation 0x193b12278 \___forwarding___
4 CoreFoundation 0x193a0c59c _CF_forwarding_prep_0
5 MyProjectTargetName 0x100087518 -[BannerContainer pressed:] (BannerContainer.m:105)
6 UIKit 0x199f3059c -[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:]
7 UIKit 0x199f33ca4 _UIGestureRecognizerSendTargetActions
8 UIKit 0x199af52e8 _UIGestureRecognizerSendActions
9 UIKit 0x199993828 -[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:]
10 UIKit 0x199f23ce8 _UIGestureEnvironmentUpdate
...
The thing is, in line 105, inside of BannerContainer.m "Bannercontainer pressed:" IBAction, there's an apparently easy assignation:
if(self.banners==nil || [self.banners count]==0)
{
return;
}
NSInteger position=self.currentPosition; // both NSIntegers
if(IS_IPAD) // Macro working perfectly as of today
{
position=((UIButton *)sender).tag; // this is offending line 105
}
According to Crahslytics, the NSInvalidArgumentException is crashing in line 105... But I can't identify any "invalid argument" there. Instead I would say it's just a button and its (NSInteger) tag attribute being assigned onto a NSInteger variable (sender is ALWAYS a button, as this function is linked to 5 UIButtons inside the .xib file). These 5 buttons have 5 different tags (0, 1, 2, 3 and 4 ). if sender is nil, that line doesn't even crash (I manually set sender to nil to check this claim 5 minutes ago).
Whatever, the thing is I've never been able to make my app crash ON THIS line, as apparently crashlytics says some people in-field have been able to do.
I'm somehow clueless. Any hint? Any rubber-duck debugging someone can guide me through? Why Crashlytics is able to find a crash condition I can't find in my development environement?
Greetings.
EDIT: I don't have access to that Crashlytics account. This crash I posted is just a .txt dump my customer sent us via email. I don't have nor access to this app production environment servers neither to my customer itunes connect account. I just deliver my code to my customer, and then he compiles, signs and uploads everything with his accounts.
Problem "solved" (Can't say for sure though!!).
Well, as was expectable from debug, sender seemed not to be an UIButton.
Apparently, when my app crashed under crashlytics it was because sender was actually a "UITapGestureRecognizer" (as some of you have pointed and was deductable from debug).
But more things had happened also: my customer sent me better info about his crashlytics crash.txt dump, that is, he told me additional info appearing in some other lines of his Crashlytics web interface, these lines made me review other code parts of my app (It was some code written by another person in the past) and that lead me to the correct conflicting lines.
Reviewing these new code parts and files I finally discovered someone was registering tap gestures "on top of my buttons" (to say it somehow) somewhere else in the life cycle of that controller. These gestures were assigned the same "pressed button" IBAction function than I had linked for my real buttons in IB.
This makes sense in the iPhone version of my app (where we don't have buttons, but views, so we need to capture gestures on top of them), but overlaps with ipad version of my app (the crashlytics crashing one), which DOES have buttons to capture clicks.
So, to solve this situation I just removed the selector registering lines for tap gestures, and no more tap gestures get registered when this controller initializes (all this in ipad mode).
Starting from today, Crashlytics shouldn't crash anymore because of this, but I will only know it for sure in some weeks, once this version gets published.
And still, I haven't been able to make this piece of faulty code crash with my own hands, so my worry is still not 100% eased. I'm more than sure I've solved it, but I don't feel total victory.
Greetings and thanks for your help and analysis.
Very often crash appears with following stack:
0x000cc1c8 NR_timeElapsedInMilliSeconds in NRTimer.m on Line 54
0x000f70ea +[NewRelic noticeNetworkRequestForURL:withTimer:responseHeaders:statusCode:bytesSent:bytesReceived:responseData:andParams:] in NewRelic.m on Line 93
0x000cfd7a __41-[NRURLProtocol handleDidReceiveResponse]_block_invoke in NRURLProtocol.m on Line 431
Please can you assist
It seems very likely that this issue is resolved by an update of the New Relic for Mobile Apps iOS SDK. We realize this isn't great news, because updating your app is non-trivial. However, this does look like an issue that is fixed in our most recent agent version: https://docs.newrelic.com/docs/releases/ios
The first step would be to verify that you've got the latest version of the New Relic for Mobile Apps iOS SDK. After that, you'll probably need to get in touch at support.newrelic.com. For a crash like this one, New Relic will ask for the following information (I'm happy to let you know what information New Relic will probably need to investigate, but I don't think all this info is necessarily appropriate to post publicly, so do use a support ticket at support.newrelic.com):
1) I'd like to get a sense of the scope of this issue: was it reported for a single user, multiple users, or is this consistent and replicable in your development environment?
2) A crash log with symbols is helpful for initial troubleshooting, and several third party error reporting services (Crashlytics, TestFlight, Airbrake, etc.) will provide useful stack traces. Please paste any stack traces if you have them. If you're using Apple's crash reports service, you can do the following:
Log in to https://itunesconnect.apple.com
Go to "Manage Your Applications"
Choose your application by clicking on its name
Click the "View details" button under the Versions table
Click "Crash Reports" link
If you don't see any reports, press "refresh"
3) If this can be replicated in your dev environment, I'd like to run some logging from the New Relic for Mobile Apps iOS SDK during the crash. Turn up the logging level in the app by adding this method call before calling startWithApplicationToken:
[NRLogger setLogLevels:NRLogLevelALL];
To make this change take effect, hit “Run” in Xcode and let the iOS Simulator launch. Copy and paste the entire contents of the simulator or device console output while running the app. (press Shift-Command-C to show the debug console in Xcode).
4) Also, please attach your AppDelegate.m to this ticket so that we can take a closer look at how you’ve implemented the New Relic agent in your app. You can find the location of the file by selecting it in the application's project in Xcode, then choosing File > Show in Finder.
5) Finally, please include a permalink to the where the app is reporting to the New Relic user interface. To create a permalink to any page within the New Relic user interface, scroll to the bottom and click 'Permalink ∞' all the way on the right next to 'Kiosk Mode.' This will show us the exact page and time period that you are observing.
#Toby_New_Relic, please find answers below
1) It reproduces not just on one device. As I see it is only iPhone 5S.
2) Stack:
2 libsystem_platform.dylib 0x38284722 _sigtramp
3 libsystem_pthread.dylib 0x38289a52 pthread_kill
4 libsystem_c.dylib 0x381d302c abort
5 libsystem_c.dylib 0x381b2c6a __assert_rtn
6 MyApp 0x000bd760 NR_timeElapsedInMilliSeconds in NRTimer.m on Line 54
7 MyApp 0x000e8682 +[NewRelic noticeNetworkRequestForURL:withTimer:responseHeaders:statusCode:bytesSent:bytesReceived:responseData:andParams:] in NewRelic.m on Line 93
8 MyApp 0x000c1312 __41-[NRURLProtocol handleDidReceiveResponse]_block_invoke in NRURLProtocol.m on Line 431
9 MyApp 0x000e0c78 __NR__dispatch_async_block_invoke in NRGCDOverride.m on Line 38
10 libdispatch.dylib 0x381570c2 _dispatch_call_block_and_release
11 libdispatch.dylib 0x3815c7d8 _dispatch_root_queue_drain
12 libdispatch.dylib 0x3815c9c4 _dispatch_worker_thread2
13 libsystem_pthread.dylib 0x38286dfe _pthread_wqthread
14 libsystem_pthread.dylib 0x38286cc3 start_wqthread
3) I can't replicate this issue on dev env
4)
I just added to pch
#import <NewRelicAgent/NewRelic.h>
and to application:didFinishLaunchingWithOptions:
[ NewRelicAgent startWithApplicationToken: <APPLICATION_TOKEN> ];
5) Permalink
https://rpm.newrelic.com/accounts/47982
I'm having trouble finding a bug in my app because it only presents itself after an adhoc installation. I have narrowed it down to [self.mapview removeOverlay:overlay]; and '[self.mapview addOverlay:overlay]. The exact same code with the exact same steps works just minutes before if I install and debug via Xcode (4.6.1). I'm not changing any other settings in between tests. I just Archive and distribute the app, or I press the Run button and it gets pushed to my iPad. One time it works, one time it fails.
Xcode->device = overlays can come and go as I want
Xcode->adhoc->server->device = complete app freeze when I try to remove a visible overlay or add one that is within the area the map can see right now
I've looked at the crash logs on the device and it always within [MKOverlayClusterView didAddSubview:] or [MKOverlayClusterView willRemoveSubview:]
Here's the main thread as shown in the crash log
0 libsystem_kernel.dylib 0x3c4ff27c __psynch_rw_wrlock + 24
1 libsystem_c.dylib 0x3c44fbd6 pthread_rwlock_wrlock + 334
2 MapKit 0x34fb321e -[MKOverlayClusterView willRemoveSubview:] + 50
3 UIKit 0x3614b2d2 __UIViewWillBeRemovedFromSuperview + 126
4 UIKit 0x35f93844 -[UIView(Hierarchy) removeFromSuperview] + 52
5 MapKit 0x34fae5b0 -[MKOverlayContainerView _removeOverlayView:forOverlay:coalesce:] + 24
6 MapKit 0x34fae118 -[MKOverlayContainerView removeOverlays:] + 240
It's worth noting that in both the add/remove variants the last top of the stack is the same so perhaps this is an issue with pthread_rwlock_wrlock meaning I've crossed threads at some point. I have tried to protect against this by using [self performSelectorOnMainThread:#selector(mainThreadRemoveOverlays:) withObject:#[overlay] waitUntilDone:YES]; but the crash keeps happening when the app is installed via the adhoc method and never happens when debugging via Xcode.
I had something similar problem. I was adding a map overlay to a map.
Worked fine when testing but not for Ad hoc deployment. My solution was that I had put the wrong case. I was using map.jpeg when the file name was actually Map.jpeg.
Map.jpeg != map.jpeg
As the map was working on test I just assumed that was the correct name. Took me a while to find out this was the problem. Not sure why my iPhone 5 or simulator did not pick this up.
Also it is good to Clean your project before deploying.
Hope this helps
I have a problem in understanding some things about these two crash reports that I get from Apple:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x617401fa
Crashed Thread: 0
0 app 0x0017c0ca Json::parse(int, JSON_value_struct const*) + 378
1 app 0x0017bf46 Json::parse(void*, int, JSON_value_struct const*) + 2
2 app 0x001302d2 JSON_parser_char + 2070
3 app 0x0017bb58 Json::parse(std::string const&) + 356
4 app 0x0008e682 NotificationData::ProcessNotifications(std::vector<UserEvent, std::allocator<UserEvent> >&) + 1062
5 app 0x00106aea SMS::CheckNotifications() + 106
6 app 0x001073dc SMS::update(Rex::TimeData const&) + 936
7 app 0x00192c7e SceneManager::updateTick(TimeData const&) + 314
8 app 0x001685ae Core::onRender(TimeData const&) + 522
and
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xffff0202
Crashed Thread: 0
0 app 0x0017c0ca 0x1000 + 1552586
1 app 0x0017bf46 0x1000 + 1552198
2 app 0x001302d2 0x1000 + 1241810
3 app 0x0017bb58 0x1000 + 1551192
4 app 0x0008e682 0x1000 + 579202
5 app 0x00106aea 0x1000 + 1071850
6 app 0x001073dc 0x1000 + 1074140
7 app 0x00192c7e 0x1000 + 1645694
8 app 0x001685ae 0x1000 + 1471918
Some facts first: the first is said to occur 40% of the time and the second time 35%. If this is true it's quite a good thing for me.
My reasoning based upon what I read about this stuff is that they are one and the same because the memory adresses of the functions are exactly the same, just the KERN_INVALID_ADDRESS at 0x617401fa and KERN_INVALID_ADDRESS at 0xffff0202 differ, which would be expected because the function was writting some corrupt file on disk
My first question is why do the crash reports sometime come symbolicated (or partially symbolicated) and other times not? (I just got into analyzing them and our build system wasn't saving the dSYM files generated for each build so I can't do much thing about symbolicating the second one)
The second one is how is it possible for a crash report to come symbolicated from the user? As I looked into the project , the settings for the released build are like this: the GCC_GENERATE_DEBUGGING_SYMBOLS is set to NO for ALL_BUILDS and and the target application level debug_information is set to dwarf with dSYM file and generate debug symbols is set to No. ( Side question: When it is built with these settings there is no dSYM generate but if I magically set the GCC_GENERATE_DEBUGGING_SYMBOLS to true from cMake(...) the dSYM is generated. As I read target level settings override build level settings)
Sorry for the long post, it's my first one.
Regarding the facts: it is 40% of the crashes that iTunes gets! That is by far not all crashes your app has. iTunes Connect only shows crashes from devices, where the user did approve sending anonymous usage data when setting up the device (since iOS 5 can be changed deep in the settings app later on). And only a fraction of users enable that, since they don't want to be tracked. On systems pre iOS5 crash reports are also only send once the device gets synced with iTunes.
So in a nutshell: Crash Reports on iTunes Connect do not give you a real view on crash reports. Here an example blog post about this fact from the Camera+ developers: http://taptaptap.com/blog/cameraplus-2-3-1-available-attack-of-the-crashinator/
Those two crash reports are identical, you are correct.
Question 1: All crash reports on the device are send to Apple not symbolicated. The symbolication happens on Apple's servers. And since they still get a damn lot of crash reports (even though only a fraction of what really happens) they only symbolicate 1 report per group to reduce load on their servers.
The symbolication of the second one would show the same result as the first one, since the memory addresses are identical.
Question 2: Apple uses the symbols from the app binary if they are not stripped from it. They don't use the dSYM nor do they have or want it. Disadvantage of this way: you don't get line numbers and the binary executable is 30-50% larger. The relevant build setting is COPY_PHASE_STRIP. I assume that is set to NO in your case.
Regarding settings level: select the project in Xcode, then the target, View the build settings not as Combined but as Levels. The value on the far left (Resolved column) is the one being used. If you are using build settings in .xcconfig files, they are usually set per build configuration on project level, target overwrites these if set differently.