I have crash logs from an iPhone Application in the App Store (retrieved via iTunes Connect) that after symbolicating have a bunch of "<redacted>" method names from CodeData and CoreFoundation.
The original crash log file from iTunes Connect looks like:
Last Exception Backtrace:
0 CoreFoundation 0x34a0929e __exceptionPreprocess
1 libobjc.A.dylib 0x32d1997a objc_exception_throw
2 CoreData 0x3631fec2 -[NSSQLCore _obtainOpenChannel]
3 CoreData 0x363cfd9c newFetchedRowsForFetchPlan_MT
4 CoreData 0x363b3be6 -[NSSQLCore newFetchedPKsForSourceID:andRelationship:]
5 CoreData 0x363a6008 -[NSSQLCore newValueForRelationship:forObjectWithID:withContext:error:]
6 CoreData 0x3635690a -[NSFaultHandler retainedFulfillAggregateFaultForObject:andRelationship:withContext:]
7 CoreData 0x36326d48 -[_NSFaultingMutableSet willRead]
8 CoreData 0x3632767c -[_NSFaultingMutableSet allObjects]
The log looks like this after symbolicating on my Mac:
Last Exception Backtrace:
0 CoreFoundation 0x34a0929e <redacted> + 158
1 libobjc.A.dylib 0x32d1997a objc_exception_throw + 26
2 CoreData 0x3631fec2 <redacted> + 230
3 CoreData 0x363cfd9c <redacted> + 948
4 CoreData 0x363b3be6 <redacted> + 2590
5 CoreData 0x363a6008 <redacted> + 528
6 CoreData 0x3635690a <redacted> + 478
7 CoreData 0x36326d48 <redacted> + 220
8 CoreData 0x3632767c <redacted> + 20
9 [myappname] [memory addresses here]
...
Can anyone help find why "<redacted>" gets added to the symbolicated versions?
Symbols from my own App are symbolicated fine, as are basic libobjc symbols as you can see above.
UPDATE: Switched around the logs to be clearer after Kerni's answer
I had the same problem and got rid of messages by deleting all iOS 6.0 (including beta) data from ~/Library/Developer/Xcode/iOS DeviceSupport.
Now, symbolicate uses the symbol data stored at /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/6.0 (10A403)/ instead of the stored symbol data in user library.
As far as I understand you: The 1st report is downloaded from iTunes Connect, the second one is after you processed it on your Mac.
<redacted> is being used by iOS when resolving some system symbols for some parts of some system libraries when writing the crash report on the device. There is nothing you can do to make this not happen other than symbolicating it again on your Mac.
Update: The symbolication script reprocesses all lines and since one of the iOS 6 beta releases Apple started to report these <redacted> symbols. Which also means older versions of atos will return <redacted> instead of the proper symbol.
Please check if Xcode 4.5 is installed with the iOS 6 symbols present and also that Xcode 4.5 is currently selected. You need to make sure that your system uses the latest version of atos.
The symbolication script is using xcrun to find the atos binary, so you can check if it finds the correct one with the following command:
xcrun -find -sdk iphoneos atos
This should point to the Xcode 4.5 app package.
Related
I have started getting huge number of the crash reported from Fabric for my iOS application which is already distributed on the App Store. Crashes are started reporting from 18 Sep onwards for iOS 13 only. Here is the crash log for the main thread which is getting crashed.
Crashed: com.apple.main-thread
0 CoreFoundation 0x185180408 OUTLINED_FUNCTION_0 + 4
1 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
2 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
3 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
4 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
5 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
6 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
7 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
8 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
9 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
10 CoreFoundation 0x18525bd68 __CFStringCollectionCopy.cold.1 + 14
Anyone facing a similar crash? How can I get rid of this issue?
My app has same situation.
After I change data protection to "Complete until first user authentication", my app is no more crash about it.
As par Alex's solution,
It seems that the dyld3 saves the generated clojure files in the app
tmp directory and if you use NSFileProtectionComplete the closure
files have this property too.
To generate a crahs close the app, lock the phone, send a push that
will wake up the app and then the crash is generated.
The solution seems to be simple, just change the permissions for the
app tmp direcptry to
NSFileProtectionCompleteUntilFirstUserAuthentication and the app will
not crash. I really don't know why apple did this.
This worked for me.
Reproduction & Test
Rayns comments
You don't necessarily need to use push notifications to reproduce the
issue. If your app is configured to use complete file protection in
the entitlements, any code that runs while protected data is
unavailable will cause the app to crash. For example, my company's app
has a background task that takes longer than 10 seconds to execute.
Since protected data becomes unavailable around 10 seconds after
locking the device, the app will crash before the background task can
finish executing (despite having more time available on the
assertion).
I am noticing it from my last few build, crashlytics is not sending the proper crash reports...
In crash reports i can not debug on which class the crash occured..
Although I have tried uploading DSYM manually also and using fabric also, I do have followed all the instructions on their website..
I have also tried by uploading DSYM by downloading from itunesconnect but not nothing gives proper crash log
Sample Crash report
Fatal Exception: NSRangeException
0 CoreFoundation 0x18cbcefe0 __exceptionPreprocess
1 libobjc.A.dylib 0x18b630538 objc_exception_throw
2 CoreFoundation 0x18caad200 -[__NSArrayM removeObjectAtIndex:]
3 MyApp 0x1001a3550 _hidden#4208_ (__hidden#4311_:498)
4 MyApp 0x10012c008 _hidden#1377_ (__hidden#1463_:318)
5 MyApp 0x10012f888 _hidden#1403_ (__hidden#1463_:753)
6 MyApp 0x100132448 _hidden#1497_ (__hidden#1511_:352)
7 MyApp 0x1001dc1b8 _hidden#5257_ (__hidden#5321_:209)
8 Foundation 0x18d6c24cc __NSThreadPerformPerform
9 CoreFoundation 0x18cb7d42c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
10 CoreFoundation 0x18cb7cd9c __CFRunLoopDoSources0
11 CoreFoundation 0x18cb7a9a8 __CFRunLoopRun
12 CoreFoundation 0x18caaada4 CFRunLoopRunSpecific
13 GraphicsServices 0x18e514074 GSEventRunModal
14 UIKit 0x192d65058 UIApplicationMain
15 MyApp 0x10018b9cc main (__hidden#3728_:14)
16 libdyld.dylib 0x18bab959c start
Why it is _hidden#4208??
Try this
Goto to Build Settings
then goto Build Options
In build options goto Debug Information Format
and Change Debug's DWARF to DWARF with DSYM File.
Now again follow Fabric crashlytics steps and you will definitely get the proper crash report.
Refer below screenshot
Please go through this Matt's answer on Xcode Bitcode, Include Symbols settings effect on dSYM generation
I've not tried it, but I think by following the guidelines mentioned in Matt's answer you can resolve your query.
My issue was, I was creating the build using command line tools and no bitcode flag was used that time for it. so it was giving improper crash reports to me.
Now I include bitcode symbols in my IPA and then after uploading it to appstoreconnect.apple.com if I download the dsym's for my IPA and upload it to crashlytisc's missing dsym section I do get all proper crash reports.
Note : I Downloaded the DSYM from the build uploaded to appstoreconnect, as that DSYM includes symbols and only that solved my issue.
finally find exact solution set Enable bitCode as a No in build setting
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 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.
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!