I am working on an iPhone app which already has approx thousands of active users across globe. The app already has crashlytics integrated.
Previously the app has CoreData related issues, which used to get reported on crashlytics and those issues state that the crash occurred in CoreData related class. But recently I am getting a frequent crash from a user who has iPhone Xs Max. The error does not have much detail, which could be helpful. The crash shows this stack
0 libsystem_platform.dylib 0x1b3bdbf64 os_unfair_lock_lock + 16
1 CoreFoundation 0x1b3da9bc4 -[__NSDictionaryM
dealloc] + 76 2 (Missing) 0x7c1b7c81b3c0a400
(Missing) 3 (Missing) 0x0 (Missing) 4 (Missing)
0x0 (Missing)
The log shows around 500mb of free ram.
The Crash log looks like this
I've tried in every way but couldn't find the issue.
I have many phones but not iPhone Xs Max. All tests go bug free and crash free.
Please Let me know if anyone of you observing same thing in latest iPhones and have found any solution.
Related
I have a build of my app that only crashes when running instruments. The repro case is 100%, but does not crash when running a release build without instruments nor when running a debug build. As Instruments runs a release build I can;t step through and figure out exactly what is crashing. When the build crashes, it does so silently, with no output that I can find. It only crashes with Allocations running in instruments.
I am having difficulty tracking down what is happening, Is there an instruments mode I am not aware of that will trap this error and report the specifics to me?
I have read similar questions on Stackoverflow but those questions have not helped me.
The crash acts like a zombie, but only happens when instruments are running, and 'zombie detection enabled' doesn't indicate a zombie.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
CoreSimulator 209.19 - Device: iPad Air 2 - Runtime: iOS 9.3 (13E230) - DeviceType: iPad Air 2
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libswiftCore.dylib 0x0000000109f03dc0 swift_retainCount + 0
1 liboainject.dylib 0x000000010335d223 oa_swift_tryRetain + 297
2 libswiftCore.dylib 0x0000000109f14d69 -[SwiftObject retainWeakReference] + 9
3 libobjc.A.dylib 0x00000001098b8b6b weak_read_no_lock + 89
4 libobjc.A.dylib 0x00000001098b94c6 objc_loadWeakRetained + 104
5 libobjc.A.dylib 0x00000001098b94f2 objc_loadWeak + 15
6 com.apple.Foundation 0x0000000108da975c empty + 35
7 com.apple.Foundation 0x0000000108da96fa -[NSConcreteHashTable dealloc] + 46
8 libobjc.A.dylib 0x00000001098b9afe objc_object::sidetable_release(bool) + 232
9 liboainject.dylib 0x000000010335c6e9 ___swapMethods_block_invoke_4 + 272 ````
It happens the same things to me on Xcode 9 using the iOS 10 simulator, default is iOS 11 simulator but I wanted to test also on iOS 10.
So far so bad, any instrument manipulation is causing my application to crash with almost the same backtrace than the one shown here when using iOS 10 simulator.
I tried many things and at last I thought that there may be some incompatibility of Xcode 9 Instrument with older simulator SDK.
So I switched to the iOS11 simulator which is the default one on Xcode 9 and it solve my Instruments issue.
I'm now able to use instrument for memory investigation on my app.
My app crash on start up, on splash screen. After it crashes, double click home button, and I find that it is in "app gallery", just like as if it went to the background. Click it, splash window came again and this time, it launch normally. This very strange.
I've got the crash log, but I lost the dSYM file for some reason, so I can't exactly locate the bug. The crash log is just like this:
(yes, only one thread in crash log; there should be many in fact.)
0 CoreFoundation 0x0000000182538f60 <redacted> + 148
1 libobjc.A.dylib 0x0000000197087f80 objc_exception_throw + 56
2 CoreFoundation 0x0000000182538e90 <redacted> + 0
3 stockmap-ios 0x00000001005d6fc4 stockmap-ios + 5156804
4 libsystem_platform.dylib 0x0000000197ab593c _sigtramp + 52
5 stockmap-ios 0x00000001003fa7ec stockmap-ios + 3205100
Another thing make me upset is that, I can only reproduce this crash on production mode (after build to .ipa), but I'm not able to do this on development mode. That makes me crazy... As you know I lack dSYM so the crash log is to some extent useless.
For my code, What are the differences between this two modes?
env info:
os: ios 9
device: at least, happens on Ipad2, Iphone6, Iphone6s. unknow about others.
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.
I am beginning to receive crash reports from my iOS app via BugSense. I have included the debug symbols in my app and an getting info on the errors, eg. "* -[NSMutableArray objectAtIndex:]: index 0 beyond bounds for empty array" and also stacktraces such as:
Full Stacktrace
0 CoreFoundation __exceptionPreprocess 114
1 libobjc.A.dylib objc_exception_throw 24
2 CoreFoundation -[__NSArrayM objectAtIndex:] 184
3 Myapp Myapp 738167
4 UIKit -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] 662
5 UIKit -[UITableView _userSelectRowAtPendingSelectionIndexPath:] 130
6 Foundation __NSFireDelayedPerform 368
7 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ 14
8 CoreFoundation __CFRunLoopDoTimer 850
9 CoreFoundation __CFRunLoopRun 1088
10 CoreFoundation CFRunLoopRunSpecific 230
11 CoreFoundation CFRunLoopRunInMode 58
12 GraphicsServices GSEventRunModal 114
13 GraphicsServices GSEventRun 62
14 UIKit -[UIApplication _run] 404
15 UIKit UIApplicationMain 670
16 Myap p Myapp 11901
17 Myapp Myapp
However, I want to symbolicate the reports so that I can pinpoint exactly where the bugs are in my code. How can I take the report data from Bugsense and do this? Is there a way to download the "regular" crash report from BugSense and use that, or is the data they provide enough to work off of somehow? I know which version of the app that the reports are coming from so i know which binaries to symbolicate against.
BugSense works by getting the symbols on the device and posting them on the server, in a format similar to what you see in a crash log. BugSense gets the exception stacktrace and when it can't find one, the crashed thread stacktrace. For a variety of reasons, this isn't always perfect.
The stacktrace that you posted is partially symbolicated. It looks like BugSense has a problem getting the symbols in your own code.
If you have followed the usage guide to the letter, it could be a failing of the framework itself. atos should help you discover the exact method calls in your code.
Disclaimer: I write the code for BugSense-iOS.framework.
If you have a free BugSense account, it wont Symbolicate the crash reports for you. However you can pay $19/month to enable this feature. Alternatively you can try use this python script I wrote.
https://github.com/dr4ke616/Bugsense-Symbolicater
You could also try symbolicating with Crittercism. I've been using them for the past month and their symbolification system has been spot on.
Just had to go through this myself today. I found a tutorial on the Ray Wenderlich site:
http://www.raywenderlich.com/33669/overview-of-ios-crash-reporting-tools-part-1
I had been using Bugsense the wrong way (without symbolicate and breadcrumb >.<).
Note: breadcrumb is for the rather expensive version.
How to upload dSYM to Bugsense website to symbolicate stacktrace
Anyhow, from the tutorial, I found out I needed to upload the dSYM folder as a zipped file to Bugsense.
This folder essentially allows the raw stacktrace to symbolicate with which function calls caused the crash, also showing line number.
When you do an archive, you get the archive file in Window > Organizer.
To get the dSYM file, you need to:
Right click the archive > Show In Finder from the Window > Organizer
screen.
Then right click the file > Show packaged contents, this will show you the dSYM folder.
Right click and zip that folder up.
Login to your bugsense account, look for your app, go to the settings page and there should be a tab on the left called "dSYM". Tap on that and then press the Browse & Upload button to upload your dSYM.
Now you can go to each of your bug and press the "symbolicate" button, this will turn all those nasty:
0000x1aeaf390a
crash messages to something like:
MyViewController:m110, [MyViewController objectAtIndex:17] out of bounds
You need to upload the respective dSYM zipped file for the respective archive that you generated everytime you generate a new bundle version of your app.
Otherwise, if you try to use Bugsense without this dSYM, you'll get a useless stacktrace.
Hope that benefits anyone in the future. Good luck!
I just recently upgraded my project to iOS 5 with ARC (automatic reference counting) and now Instruments is reporting a memory leak from NSAutoreleasePool after I suspend the app in the background.
I suspect the leak is being caused by Flurry Analytics based on the stack trace with these two API calls:
+[FlurrySession sendSessionsToServerForSessionPause]
+[FlurrySession sendSessionsToServerWithTimeout:useWebView:requestAppCircleAds:requestVideoAds:requestAppSpotAds:sendCurrentSession:]
I'm not making any Flurry API calls on suspend. The only call being made to flurry is
[FlurryAnalytics startSession:<my id>];
when the app first starts.
Reported leak
Leaked Object # Address Size Responsible Library Responsible Frame
NSAutoreleasePool,1 0x7693f600 32 Bytes Foundation +[NSAutoreleasePool allocWithZone:]
Stack trace
10 libsystem_c.dylib thread_start
9 libsystem_c.dylib _pthread_start
8 Foundation __NSThread__main__
7 Foundation -[NSThread main]
6 iSURVEY +[FlurrySession sendSessionsToServerForSessionPause] /Developer/Applications/iPhoneAdAgent_modular/Classes/FlurrySession.m:931
5 iSURVEY +[FlurrySession sendSessionsToServerWithTimeout:useWebView:requestAppCircleAds:requestVideoAds:requestAppSpotAds:sendCurrentSession:] /Developer/Applications/iPhoneAdAgent_modular/Classes/FlurrySession.m:962
4 CoreFoundation +[NSObject(NSObject) alloc]
3 Foundation +[NSAutoreleasePool allocWithZone:]
2 CoreFoundation +[NSObject(NSObject) allocWithZone:]
1 libobjc.A.dylib class_createInstance
0 libsystem_c.dylib calloc
Edit:
I just tried turning off all debug variables like zombies and the memory leak is still exactly the same.
Edit 2:
Okay I've confirmed that it definitely is a Flurry issue. After removing the call
[FlurryAnalytics startSession:<my id>];
I no longer get the memory leak.
I'll file a bug with the Flurry team.
I see the same 32 byte leak. I was thinking about releasing it that way, and watching for an update. A one time 32 byte leak doesn't seem like it's a big problem. I only see it when the App registers with Flurry, not every time the task comes out of the background. I'm using Flurry version 3.0.2 with iOS 5.0 as the base SDK, and a target of iOS 4.1
Looking at the Flurry docs, it looks like you can set it up to only report on application launch.
Before your
[FlurryAnalytics startSession:id];
Add the following two calls:
[FlurryAnalytics setSessionReportsOnCloseEnabled:NO];
[FlurryAnalytics setSessionReportsOnPauseEnabled:NO];
The docs say that "OnPause" is off by default, but it can't hurt to be sure.
I also filed a bug report with Flurry.