I'm new to PLCrashReporter. I have a question regarding symbolication of crash data. I use PLCrashReporter API to read crash data and send it to a server. After that point, i use symbolicate crash script to symbolicate the crash report.
The problem is; I have ~10 projects in my workspace. When I generate my app which is shell.app , build process also generates the shell.app.dSYM file. Therefore, I use this .dSYM file to symbolicate in symbolicate script. However, it only symbolicates the hex codes that belong to shell project. See example below.
Thread 3 name: Exception Backtrace
Thread 3:
0 CoreFoundation 0x021c0022 0x20c2000 + 1040418
1 libobjc.A.dylib 0x00b11cd6 0xb0c000 + 23766
2 CoreFoundation 0x02168a48 0x20c2000 + 682568
3 CoreFoundation 0x021689b9 0x20c2000 + 682425
4 shell 0x0004bd78 -[DocumentHubApplicationBarContentView applicationBarButtonTapped:] (DocumentHubApplicationBarContentView.mm:85)
5 shell 0x00010657 -[ApplicationBarButton buttonTapped] (ApplicationBarButton.mm:48)
6 CoreFoundation 0x021c1e99 0x20c2000 + 1048217
7 UIKit 0x0109214e 0x1084000 + 57678
8 UIKit 0x010920e6 0x1084000 + 57574
9 UIKit 0x01138ade 0x1084000 + 740062
10 UIKit 0x01138fa7 0x1084000 + 741287
11 UIKit 0x01138266 0x1084000 + 737894
12 UIKit 0x010b73c0 0x1084000 + 209856
13 UIKit 0x010b75e6 0x1084000 + 210406
14 UIKit 0x0109ddc4 0x1084000 + 105924
15 UIKit 0x01091634 0x1084000 + 54836
16 GraphicsServices 0x026b2ef5 0x26ab000 + 32501
17 CoreFoundation 0x02194195 0x20c2000 + 860565
18 CoreFoundation 0x020f8ff2 0x20c2000 + 225266
19 CoreFoundation 0x020f78da 0x20c2000 + 219354
20 CoreFoundation 0x020f6d84 0x20c2000 + 216452
21 CoreFoundation 0x020f6c9b 0x20c2000 + 216219
22 GraphicsServices 0x026b17d8 0x26ab000 + 26584
23 GraphicsServices 0x026b188a 0x26ab000 + 26762
24 UIKit 0x0108f626 0x1084000 + 46630
25 shell 0x0000347d main (main.mm:42)
26 shell 0x00002425 start + 53
27 ??? 0x00000001 0x0 + 0
Also, I checked the crash report that is also generated by iOS and it's fully symbolicated. Also, that crash report has more information that PLCrashReporter provides. Can someone enlighten me about this? Am I missing something wrong?
Thank you
To symbolicate the iOS system framework calls, you need to have the symbols of the corresponding iOS version existing on your system and available for the symbolication script.
Regarding your question that crash report has more information that PLCrashReporter provides: Without further specifying what exactly you are referring to, this cannot be answered.
Related
We've had a few very bizarre crashes in our app recently. They are not reliably reproducable. The crashes have all occurred on iOS 11 devices so far. Our app is written in Swift 3.2. We are using Xcode 9.0.1 with the standard build system (not the new Swift build system). It seems that after performing a certain web request, the app crashes with the below stack trace:
Crashed: com.apple.main-thread
0 OurFramework 0x105283e84 __swift_deallocate_boxed_opaque_existential_0 + 2588
1 OurFramework 0x10528366c __swift_deallocate_boxed_opaque_existential_0 + 516
2 OurFramework 0x10528b368 swift_rt_swift_storeEnumTagSinglePayload + 24748
3 OurFramework 0x1052911cc swift_rt_swift_storeEnumTagSinglePayload + 48912
4 OurFramework 0x1052133d8 __swift_memmove_array32_8 + 1336
5 OurFramework 0x10521304c __swift_memmove_array32_8 + 428
6 OurFramework 0x105292504 swift_rt_swift_storeEnumTagSinglePayload + 53832
7 Alamofire 0x1057cac64 _T09Alamofire11DataRequestC8responseACXDSo13DispatchQueueCSg5queue_x0D10SerializeryAA0B8ResponseVy16SerializedObjectQzGc17completionHandlertAA0biH8ProtocolRzlFyycfU_yycfU_AA0biH0VyypG_Tg5 + 264
8 Alamofire 0x1057ca3f8 _T0Ix_IyB_TR + 36
9 libdispatch.dylib 0x1860c5088 _dispatch_call_block_and_release + 24
10 libdispatch.dylib 0x1860c5048 _dispatch_client_callout + 16
11 libdispatch.dylib 0x1860d1b74 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1016
12 CoreFoundation 0x1866e9eb0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
13 CoreFoundation 0x1866e7a8c __CFRunLoopRun + 2012
14 CoreFoundation 0x186607fb8 CFRunLoopRunSpecific + 436
15 GraphicsServices 0x18849ff84 GSEventRunModal + 100
16 UIKit 0x18fbdc2e8 UIApplicationMain + 208
17 OurApp 0x104de98b0 main (main.swift:19)
18 libdyld.dylib 0x18612a56c start + 4
We are using Crashlytics to track our crashes and I'm not sure if it's because of a symbolication issue that I don't see more info than this but the trace indicates that something is going awry during a web request. Our app uses Alamofire to make web requests. Results from our testing where this crash occurred also support this theory since the crashes always occurred right after the app made a request to our backend. Could it be that in iOS 11 something changed in the underlying NSURLSession that Alamofire uses? Maybe iOS 11 is using a different caching strategy or something that's causing alamofire to invoke our result completion handler in a way that causes this crash? Has anyone seen this kind of crash before? What do __swift_deallocate_boxed_opaque_existential and swift_rt_swift_storeEnumTagSinglePayload mean? Any help is greatly appreciated, thank you!
Along with crash report, I've .app and .dSYM package as well. I'm trying to symbolicate the crash report by running the following command
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash crash.crash > SymbolicatedPaperio.crash
The first few lines of exception stack trace looks like,
Last Exception Backtrace:
0 CoreFoundation 0x00000001898a61c0 0x189777000 + 1241536
1 libobjc.A.dylib 0x00000001882e055c 0x1882d8000 + 34140
2 CoreFoundation 0x00000001898a6094 0x189777000 + 1241236
3 Foundation 0x000000018a333808 0x18a285000 + 714760
4 UIKit 0x000000018f984848 0x18f6f1000 + 2701384
5 UIKit 0x000000018f9a4fac 0x18f6f1000 + 2834348
6 CoreFoundation 0x00000001898537dc 0x189777000 + 903132
7 CoreFoundation 0x000000018985140c 0x189777000 + 893964
8 CoreFoundation 0x0000000189780068 0x189777000 + 36968
9 paperio 0x00000001000b0d80 0x1000a4000 + 52608
10 paperio 0x00000001000bf0fc 0x1000a4000 + 110844
11 UIKit 0x000000018f768f3c 0x18f6f1000 + 491324
12 UIKit 0x000000018f987158 0x18f6f1000 + 2711896
13 FrontBoardServices 0x000000018b4365e8 0x18b413000 + 144872
14 Foundation 0x000000018a345794 0x18a285000 + 788372
15 BaseBoard 0x000000018b3b0f00 0x18b37e000 + 208640
16 FrontBoardServices 0x000000018b4306a8 0x18b413000 + 120488
17 FrontBoardServices 0x000000018b4363c4 0x18b413000 + 144324
18 UIKit 0x000000018f9885c0 0x18f6f1000 + 2717120
19 UIKit 0x000000018f988264 0x18f6f1000 + 2716260
20 UIKit 0x000000018fcb9ba4 0x18f6f1000 + 6065060
For the first line, on my mac, it is not symbolicated and the output remains same (as the non-symbolicated line above). However, on a different mac, I can see the output as:
0 CoreFoundation 0x00000001898a61c0 __exceptionPreprocess + 124
This is happening for all the frameworks and libraries. Want to understand what possibly could be missing on my mac - that its not symbolicating properly and how to fix this.
Basically, to symbolicate libraries and framework's method, we need to have symbols for the iOS version for which crash was generated. These are (by default) present in ~/Library/Developer/Xcode\iOS DeviceSupport. So, if the symbol for correct iOS version is not present here - the symbolicator would not be able to properly decrypt the reports.
You need to specify the location of the Archive fileļ¼
./symbolicatecrash crashPath archivePath > output
Summary:
While trying to load the URL/HTML string on UIWebView console shows warning like "This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes." and crashes the app at some point.
Steps to Reproduce:
Load URL/HTML String on UIWebView.
Console will show the AutoLayout engine warning.
App Crashed some times(Uncaught exception: Only run on the main thread!).
Expected Results:
App should not show any warning while loading UIWebView and should not crash the app due to that warning.
Actual Results:
This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
Stack:(
0 CoreFoundation 0x0000000188e35998 <redacted> + 148
1 libobjc.A.dylib 0x00000001884304bc objc_exception_throw + 56
2 CoreFoundation 0x0000000188e358c8 <redacted> + 0
3 Foundation 0x00000001899a3da0 <redacted> + 192
4 Foundation 0x00000001899a3b00 <redacted> + 76
5 Foundation 0x0000000189808548 <redacted> + 108
6 Foundation 0x00000001899a2788 <redacted> + 104
7 UIKit 0x000000018ebbc76c <redacted> + 1464
8 QuartzCore 0x000000018c0e0d6c <redacted> + 148
9 QuartzCore 0x000000018c0d5aac <redacted> + 292
10 QuartzCore 0x000000018c0d596c <redacted> + 32
11 QuartzCore 0x000000018c0554fc <redacted> + 252
12 QuartzCore 0x000000018c07c7c4 <redacted> + 512
13
QuartzCor
iOS Version:
iOS 10 beta 1
Xcode version:
Xcode 8 beta
This issue has been resolved in iOS 10 beta2.
Thanks!
This issue was happening in iOS 10 beta1 and I filed an issue in Apple Bug report with sample project. Now the issue has been resolved in iOS 10 beta 2.
Thanks!
I have an iOS project called Core.proj that includes the SalesForce SDK and it is written in Objective-C. This project utilises the SF SDK and links the binary to the SF libraries. It does a bunch of stuff to help manage my implementation of SF. It is included in all my other Obj-C projects and it works absolutely fine within them.
This is the first time I am using this project with Swift (2.1). I am using iOS 9 with Xcode 7.1.1. I added the Core.xcodeproj into my Swift project. I then created an ObjC file. Xcode then asks if I want to create a bridging header. I do. I have created a bridging header called Swift-Bridging-Header.h. This enables me to access the files in Core.xcodeproj via the bridging header. For example, I can access my own version of the Salesforce Authentication Manager from the bridging header.
In my app delegate, I want to now kick off OAuth (I'm keeping this minimal here):
let sharedManager = MyAuthenticationManager.sharedManager()
let successBlock: OAuthFlowSuccessCallbackBlock = { sfAuthInfo in }
let failureBlock: OAuthFlowFailureCallbackBlock = { sfAuthInfo in }
sharedManager.loginWithCompletion(successBlock, failure: failureBlock)
Full disclosure: each block that you see here takes the SFOAuthInfo object as an argument. In order to get Swift to read this block, I had to add SFOAuthInfo.h into the copy files.
Now this all compiles fine but when I tap to login and execute the above code, I get the following error:
2015-12-04 11:53:54.879 MyApp[19108:3494140] -[UIDevice macaddress]: unrecognized selector sent to instance 0x7fcfb4903230
2015-12-04 11:53:54.890 MyApp[19108:3494140] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UIDevice macaddress]: unrecognized selector sent to instance 0x7fcfb4903230'
*** First throw call stack:
(
0 CoreFoundation 0x000000010d6adf65 __exceptionPreprocess + 165
1 libobjc.A.dylib 0x000000010f624deb objc_exception_throw + 48
2 CoreFoundation 0x000000010d6b658d -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
3 CoreFoundation 0x000000010d603f7a ___forwarding___ + 970
4 CoreFoundation 0x000000010d603b28 _CF_forwarding_prep_0 + 120
5 MyApp 0x000000010c869317 -[SFOAuthCredentials keyMacForService:] + 84
6 MyApp 0x000000010c8696b8 -[SFOAuthCredentials updateTokenEncryption] + 210
7 MyApp 0x000000010c8673ee -[SFOAuthCredentials initWithIdentifier:clientId:encrypted:] + 211
8 MyApp 0x000000010c84102c -[SFUserAccount initWithIdentifier:] + 197
9 MyApp 0x000000010c85f32d -[SFUserAccountManager createUserAccount] + 91
10 MyApp 0x000000010c831b41 -[SFAuthenticationManager loginWithCompletion:failure:account:] + 284
11 MyApp 0x000000010c831a0b -[SFAuthenticationManager loginWithCompletion:failure:] + 53
12 MyApp 0x000000010c60440c -[MyAuthenticationManager loginWithCompletion:failure:] + 124
13 MyApp 0x000000010c5dc58f _TFC18MyApp11AppDelegate5loginfS0_FT_T_ + 911
14 MyApp 0x000000010c5dfdc4 _TFC18MyApp25LandingPageViewController17loginButtonTappedfS0_FPSs9AnyObject_T_ + 68
15 MyApp 0x000000010c5dfe16 _TToFC18MyApp25LandingPageViewController17loginButtonTappedfS0_FPSs9AnyObject_T_ + 54
16 UIKit 0x000000010e1af1fa -[UIApplication sendAction:to:from:forEvent:] + 92
17 UIKit 0x000000010e313504 -[UIControl sendAction:to:forEvent:] + 67
18 UIKit 0x000000010e3137d0 -[UIControl _sendActionsForEvents:withEvent:] + 311
19 UIKit 0x000000010e312906 -[UIControl touchesEnded:withEvent:] + 601
20 UIKit 0x000000010e219aa3 -[UIWindow _sendTouchesForEvent:] + 835
21 UIKit 0x000000010e21a691 -[UIWindow sendEvent:] + 865
22 UIKit 0x000000010e1cc752 -[UIApplication sendEvent:] + 263
23 UIKit 0x000000010e1a7fcc _UIApplicationHandleEventQueue + 6693
24 CoreFoundation 0x000000010d5da0a1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
25 CoreFoundation 0x000000010d5cffcc __CFRunLoopDoSources0 + 556
26 CoreFoundation 0x000000010d5cf483 __CFRunLoopRun + 867
27 CoreFoundation 0x000000010d5cee98 CFRunLoopRunSpecific + 488
28 GraphicsServices 0x0000000113e46ad2 GSEventRunModal + 161
29 UIKit 0x000000010e1ad676 UIApplicationMain + 171
30 MyApp 0x000000010c5ddd8d main + 109
31 libdyld.dylib 0x00000001107a592d start + 1
32 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
The SF SDK has a category called UIDevice+SFHardware.h. Within this category there is a method called 'macaddress'. So clearly it is not correctly reading this category. But why? As you can see from the stack trace it is reading the other files in the SF SDK correctly.
I tried a number of things to get this to work. For example, this: iOS - UUID generation throwing a strange exception but with UIDevice+SFHardware.h. I tried this: https://developer.salesforce.com/forums/?id=906F00000009CBvIAM. I completely rebuilt the project again to check my working.
I shouldn't need to add this file into my bridge as this UIDevice+SFHardware.h is only ever accessed from SF SDK which sits within an ObjC project.
I must have done something wrong though. Any help would be greatly appreciated.
I just went through this issue.
In your Project > Build Settings > Other Linker Flags add:
-ObjC
-all_load
My SalesforceSDK is in my Pod project. If you're doing the same, set those flags in your SalesforceMobileSDK-iOS project. If not, wherever the Salesforce SDK is getting compiled.
It turns out this was a combination of things. Firstly, I was missing the -ObjC linker flag in BOTH the Swift project and the Objc project. Thanks DarthVadar123451 for pointing that out. But I also realised I was missing two libraries: libz.dylib and libxml2.dylib. Once added, everything worked. I hope that helps anyone running into the same issue.
My App does not crash on my iDevices, but the apple review team says it is crashing on ipad 6.0.1. This is the relevant part of the resymbolicated log:
Last Exception Backtrace:
0 CoreFoundation 0x327fb29e __exceptionPreprocess + 158
1 libobjc.A.dylib 0x394dd97a objc_exception_throw + 26
2 UIKit 0x38897d54 +[UIStoryboard storyboardWithName:bundle:] + 436
3 UIKit 0x386da406 -[UIApplication _loadMainStoryboardFileNamed:bundle:] + 38
4 UIKit 0x38563794 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 524
5 UIKit 0x3850bc34 -[UIApplication handleEvent:withNewEvent:] + 1000
6 UIKit 0x3850b6c8 -[UIApplication sendEvent:] + 68
7 UIKit 0x3850b116 _UIApplicationHandleEvent + 6150
8 GraphicsServices 0x35c8759e _PurpleEventCallback + 586
9 CoreFoundation 0x327d067e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 10
10 CoreFoundation 0x327cfee4 __CFRunLoopDoSources0 + 208
11 CoreFoundation 0x327cecb2 __CFRunLoopRun + 642
12 CoreFoundation 0x32741eb8 0x32739000 + 36536
13 CoreFoundation 0x32741d44 CFRunLoopRunInMode + 100
14 UIKit 0x38562478 -[UIApplication _run] + 664
15 UIKit 0x3855f2f4 UIApplicationMain + 1116
16 MyApp 0x0007362e main (main.m:16)
17 MyApp 0x000735e4 start + 36
Does this mean that the Storyboard is the problem (line 2)?
To answer your question:
Does this mean that the Storyboard is the problem (line 2)?
It means that the most likely problem is related to the storyboard loading - either with the storyboard or the bundle - as that's where the exception is being thrown from. Without knowing the source code of UIStoryboard and what's on line 436 that makes it throw an exception, that's probably about as specific as you'll get from a non-Apple employee.
To get beyond that and actually reproduce the crash locally (so you can work toward fixing it):
Validate packaging / do a clean/fresh install (as suggested in the comments)
Try on a different device (perhaps there's something leftover that a clean isn't removing properly)
Try an older iOS version (maybe they're accidentally giving you incorrect information to the iOS version?)
Try simulating low memory environment while your app is in the background (maybe the crash is related to your app closing and restarting in the background in this situation?)
More likely you'll want to get more info from the review team than just a stack trace if you can't reproduce the issue:
Can you get more exact reproduction steps on how they are causing the crash?
Is this an update to an existing app? Might they have an old version of your app that hasn't been cleaned properly?
My guess is that at some point you changed the name of the storyboard file but did not reflect that change in Xcode under (project) > (target) > General > Deployment Info > Main Interface.
Consequently, it's still working on your device (because you still have the storyboard file with the old name installed on that device, as well as the new one), but it crashes when newly-installed on other devices, where only the storyboard file with the new name exists.