I've received crash report on my submitted iOS app from apple, which is:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 APPNAME 0x00071fc8 0x6d000 + 20424
1 APPNAME 0x000733ce 0x6d000 + 25550
2 APPNAME 0x00072cc0 0x6d000 + 23744
3 Foundation 0x354cd2ee 0x354bb000 + 74478
.....
14 CoreFoundation 0x3707bebc 0x37073000 + 36540
15 CoreFoundation 0x3707bdc4 0x37073000 + 36292
GraphicsServices 0x36835418 0x36831000 + 17432
17 GraphicsServices 0x368354c4 0x36831000 + 17604
18 UIKit 0x35f25d62 0x35ef7000 + 191842
19 UIKit 0x35f23800 0x35ef7000 + 182272
20 APPNAME 0x0006ed46 0x6d000 + 7494
21 APPNAME 0x0006ed10 0x6d000 + 7440
I've also been looking at atos command and dwarfdump. I have both .dsym and the .app that was submitted to apple. However, I couldn't find a thing using the memory address given by apple (ex. 0x0006ed46, 0x00071fc8, etc. ). I tried randomizing address and found that my application address is actually between 0x0002xxx to 0x0007xxx
What happened? How can I know which part of my application causes the bug?
Best Regards,
You need to symbolicate your crash report using the dsym file. You can see the answer here:
Symbolicating iPhone App Crash Reports
Related
I'm working on an iOS app that uses Realm which is installed/managed via Cocoapods. My app crashes sporadically and I'm having difficulty troubleshooting the problem because my stack trace doesn't show me the method names related to Realm. I am deploying a debug build of my app to the phone via Xcode and I have the Debug Information Format option set to DWARF with dSYM File. In the stack trace below you can see that my code appears to be symbolicated but the method names in Realm are just addresses and offsets. Unfortunately, I'm somewhat new to troubleshooting with Xcode but I'm under the assumption that this means the Realm debug symbols could not be found? If anyone can explain to me how to correct this, I'd really appreciate it!
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Application Specific Information:
abort() called
Filtered syslog:
None found
Last Exception Backtrace:
0 CoreFoundation 0x18316ad8c __exceptionPreprocess + 228
1 libobjc.A.dylib 0x1823245ec objc_exception_throw + 55
2 Realm 0x10814e238 0x108030000 + 1172024
3 Realm 0x10814ffa0 0x108030000 + 1179552
4 Realm 0x10814ff74 0x108030000 + 1179508
5 MyAppName 0x104af31a4 closure #1 in closure #2 in processOutgoingMessage(outgoingMessage:) + 4452772 (ProcessOutgoingMessage.swift:51)
6 MyAppName 0x1046cd168 _T0Ieg_IeyB_TR + 102760 (DataSource.swift:0)
7 libdispatch.dylib 0x182a5caa0 _dispatch_call_block_and_release + 23
8 libdispatch.dylib 0x182a5ca60 _dispatch_client_callout + 15
9 libdispatch.dylib 0x182a9dd80 _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 963
10 CoreFoundation 0x183113070 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 11
11 CoreFoundation 0x183110bc8 __CFRunLoopRun + 2271
12 CoreFoundation 0x183030da8 CFRunLoopRunSpecific + 551
13 GraphicsServices 0x185015020 GSEventRunModal + 99
14 UIKit 0x18d04d758 UIApplicationMain + 235
15 MyAppName 0x104a7919c main + 3953052 (AppDelegate.swift:18)
16 libdyld.dylib 0x182ac1fc0 start + 3
UPDATE - as it turns out, the Build Settings for the Pods project (recall that I'm using Realm via Cocoapods) needed to also have the Debug Information Format set to DWARF with dSYM File for debug builds. My app hasn't crashed again yet but I did notice that when I cleaned and rebuilt the app this time it appeared to be including the debug symbols for Realm so here's hoping.
I have developed an iPad application using Xcode 6.3.2.
I submitted my application to the App Store for review where it was reject due to crash.Following is the crash report from iTunes.
Incident Identifier: 88DD7F94-3382-4241-A0D7-C3E7F6D20737
CrashReporter Key: 9881ae0cc3b3fbfccfd0ce1496d2fa08fec08782
Hardware Model: xxx
Path: /private/var/mobile/Containers/Bundle/Application/FDBBD67F-0EF7-43FB-80CB-8308A10A2D29/Vehicle Visuals.app/Vehicle Visuals
Identifier: com.vehiclevisuals.Vehicle-Visuals
Version: 2.0.0 (1.1.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
Date/Time: 2015-06-12 12:33:57.988 -0700
Launch Time: 2015-06-12 12:22:14.581 -0700
OS Version: iOS 8.3 (12F69)
Report Version: 105
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000195da7bdc 0x195d8c000 + 113628
1 QuartzCore 0x00000001889fdc2c 0x1889ec000 + 72748
2 Vehicle Visuals 0x0000000100126828 0x1000ec000 + 239656
3 Vehicle Visuals 0x0000000100101e80 0x1000ec000 + 89728
4 UIKit 0x0000000189118778 0x1890a4000 + 477048
5 UIKit 0x0000000189116750 0x1890a4000 + 468816
6 UIKit 0x0000000189112000 0x1890a4000 + 450560
7 UIKit 0x00000001890b175c 0x1890a4000 + 55132
8 QuartzCore 0x00000001889f9e18 0x1889ec000 + 56856
9 QuartzCore 0x00000001889f4880 0x1889ec000 + 34944
10 QuartzCore 0x00000001889f4724 0x1889ec000 + 34596
11 QuartzCore 0x00000001889f3eb8 0x1889ec000 + 32440
12 QuartzCore 0x00000001889f3c38 0x1889ec000 + 31800
13 UIKit 0x0000000189137f8c 0x1890a4000 + 606092
14 UIKit 0x0000000189137ef0 0x1890a4000 + 605936
15 CoreFoundation 0x000000018462c2a0 0x18454c000 + 918176
16 CoreFoundation 0x000000018462922c 0x18454c000 + 905772
17 CoreFoundation 0x000000018462955c 0x18454c000 + 906588
18 CoreFoundation 0x00000001845552d0 0x18454c000 + 37584
19 GraphicsServices 0x000000018dc436f8 0x18dc38000 + 46840
20 UIKit 0x000000018911afa8 0x1890a4000 + 487336
21 Vehicle Visuals 0x000000010013a1cc 0x1000ec000 + 319948
22 libdyld.dylib 0x0000000196412a04 0x196410000 + 10756
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
As per the report it crashes on OS Version : iOS 8.3 (12F69).
I tested my app on the all simulators(iPad Air, iPad 2, iPad Retina) with same config(iOS version 8.3 (12F69)) and also tested it on my device (iPad mini) with iOS version 8.3 (12F69), but didn't crashed on my side.
But it crashes on my friend's iPad Air with same iOS version (it gives the same crash report with different invalid address as below)
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype:
KERN_INVALID_ADDRESS at 0x0000000000000020 Triggered by Thread: 0
I don't have the iPad Air so that I could debug using the device.
I also tried to Symbolicated crash report using following command.
xcrun atos -o VehicleVisuals 0x0000000000000020
But it just gives me following hex code.
0x00000020 (in VehicleVisuals)
I following Link for symbolication.
I'm just not being able to recognise where actually is the crash issue.
Please can anybody help me out?
EXC_BAD_ACCESS usually happens because you are sending an Obj-C message to an invalid memory address, what means that you probably are trying to access some deallocated object.
It may be working on other devices because this object is not being released at the same time.
I recently had a similar crash that happened because there was a timer not being invalidated on dealloc, and when the target method was called, that object did no longer exist.
You could try to enable NSZombie objects and see if you find which object is being deallocated. In xCode 6, you can enable them in Product > Scheme > Edit scheme > Diagnostics > Enable Zombie Objects.
Also, there are lots of these kind of errors that NSZombieEnabled can't detect. Unfortunately there is nothing magical to solve it. The second option would be to run your app with instruments (memory leaks specifically) and see if you can get something. If this doesn't work you will have to review your code and check that there are no possibilities that you are trying to access a deallocated object. Hope it helps.
Good luck!
I am wondering if there is anything in the following stack trace that I received from Crashlytics that I should be concerned about:
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x000000007becbeb8
Thread : Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x3a3c61fc __pthread_kill + 8
1 libsystem_pthread.dylib 0x3a42fa33 pthread_kill + 58
2 libsystem_c.dylib 0x3a376ffd abort + 76
3 libc++abi.dylib 0x396a5cd7 abort_message + 74
4 libc++abi.dylib 0x396be6e5 default_terminate_handler() + 252
5 libobjc.A.dylib 0x39e07921 _objc_terminate() + 192
6 libc++abi.dylib 0x396bc1c7 std::__terminate(void (*)()) + 78
7 libc++abi.dylib 0x396bbd2d __cxa_increment_exception_refcount
8 libobjc.A.dylib 0x39e077f7 objc_exception_rethrow + 42
9 CoreFoundation 0x2f499c9d CFRunLoopRunSpecific + 640
10 CoreFoundation 0x2f499a0b CFRunLoopRunInMode + 106
11 GraphicsServices 0x3419a283 GSEventRunModal + 138
12 UIKit 0x31d3d049 UIApplicationMain + 1136
13 Pocket Linesman 0x0005aa8b main + 17 (main.m:17)
From my searching around the internet, I am unable to find an example of where this type of crash has an actionable fix for it. Also, I am completely unable to reproduce a crash like this through a normal interaction in my app.
Does this stack trace indicate a normal crash due to low memory issues on the user's iOS device, or something more?
This is my first app using Crashlytics, so i am still learning how to read the reports it sends me.
Thanks!
The original source of the crash is an uncaught exception. The original exception was caught and rethrown from CFRunLoopRunSpecific(). That has obscured the original source of the exception in the backtrace. Sometimes, the exception details are logged and they might indicate the original backtrace. Do you have any log messages that may have been written at the same time?
I was running into the same issue whenever the crash was caused by UI code.
Have you set NSSetUncaughtExceptionHandler in your app delegate by any chance? Setting mine caused me to get the useless pthread_kill message.
Unsetting mine in distributed builds allowed me to get more useful crash reporting from the same error.
Hope this helps :)
We have crashes in our Unity iOS app.
We cannot reproduce them when debugging, but we regularly catch this crash.
We tried to analyze crash logs. (crash log is in the bottom of the post)
We examine part of code mentioned in crash log (m_Controller... methods), and cant see something that could cause crash.
We tried to imagine situations that can occurs in that part of code, but see nothing that can lead to crash. There are small* array of strings which is loadaed from disk, and modified.
We thinking of rewriting this part of code, but we afraid that otherp part of program can affect and lead to this crash, and that crash will remain after rewriting.
We tried to add try-catch block in this part of code and process situation when exception occurs gracefully (move user to our app's main menu), but we have to remove this block due to requirements
to our app.
Also, I think that crash occurs only (or at least much more frequent) in Ad-hoc build (which uses Release configuration in Xcode).
In parts of crash logs you can see mono_gc_out_of_memory in GC_malloc, which is looking very strange to me (I thought that iOS generates memory warning when memory is low, but possibly mono has its own constraints)
Also, there is another one or two crashes in this part of code with different crash logs (without mono_gc_out_of_memory, but ), but all of them occurs in methods of ArrayList ( ArrayList.Clear() in other situations).
Can you help us with this situation?
Can you give us any advice please on how should we deal with this crashes?
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 MyApp 0x00f0e150 CrashedCheckBellowForHintsWhy() (CrashReporter.mm:73)
1 MyApp 0x00dcd888 m_wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
2 MyApp 0x01462eec mono_jit_runtime_invoke + 2152
3 MyApp 0x01504f24 mono_runtime_invoke + 132
4 MyApp 0x015050a8 mono_runtime_delegate_invoke + 128
5 MyApp 0x0150931c call_unhandled_exception_delegate + 340
6 MyApp 0x0150b230 mono_unhandled_exception + 328
7 MyApp 0x01473080 mono_handle_exception_internal + 952
8 MyApp 0x01473918 mono_handle_exception + 64
9 MyApp 0x0148f6d8 mono_arm_throw_exception + 184
10 MyApp 0x00e76ecc throw_exception + 44
11 MyApp 0x014b7f44 mono_gc_out_of_memory + 16
12 MyApp 0x0156a62c GC_generic_malloc + 452
13 MyApp 0x0156a6cc GC_malloc + 140
14 MyApp 0x015045fc mono_array_new_specific + 272
15 MyApp 0x00dd27ac m_wrapper_managed_to_native_object___icall_wrapper_mono_array_new_specific_intptr_int + 68
16 MyApp 0x00b7b2b8 m_System_Collections_ArrayList_InsertRange_int_System_Collections_ICollection + 212
17 MyApp 0x00b7b898 m_System_Collections_ArrayList_AddRange_System_Collections_ICollection + 52
18 MyApp 0x001fc3fc m_Controller_PrepareSkins_string_string_string_string_string_string_string__ + 1600
19 MyApp 0x001fda88 m_Controller_Awake + 4972
I've been getting some low level crashes lately, and this one in particular is hard to determine the origin / state of the app. Has anyone seen this or know the problem? Thanks!
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x000025fa objc_msgSend + 18
1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12
2 UIKit 0x001628de -[UIAlertView(Private) _repopup] + 10
3 UIKit 0x0016d196 -[UIAlertView(Private) _removeAlertWindowOrShowAnOldAlert] + 70
4 UIKit 0x00162afa -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 502
5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184
6 UIKit 0x000509ee -[UIViewAnimationState animationDidStop:finished:] + 34
7 QuartzCore 0x0002ee8c run_animation_callbacks(double, void*) + 284
8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96
9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
10 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
11 GraphicsServices 0x000030d4 GSEventRunModal + 108
12 GraphicsServices 0x00003180 GSEventRun + 56
13 UIKit 0x0000342a -[UIApplication _run] + 374
14 UIKit 0x00001954 UIApplicationMain + 636
15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972
16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896
Weird crashes are sometimes a symptom of memory corruption and/or mismanagement. I just found and fixed a difficult-to-find bug in one of my apps a few days ago. The app had been working flawlessly for 6 months on iOS 3.2, but would crash instantly on iOS 4.2. The crash was happening while adding the main view to the window during applicationDidFinishLaunching. The stack trace showed 100% iOS code; there wasn't a single function of mine in there anywhere (except for applicationDidFinishLaunching). It turned out I was over-releasing a UIImage in code that had been called earlier while views were getting loaded. (I was mistakenly calling release on an autoreleased UIImage).
I haven't seen the specific crash that you're seeing, but here are a few things you can try that may shed some light:
(1) Run the app with NSZombieEnabled. This is an environment variable you set via Xcode that will often identify places where you may be referencing objects that have already been freed (e.g., like the over-release example I mentioned earlier). Additional details are here:
http://www.cocoadev.com/index.pl?NSZombieEnabled
(2) You can turn on logging that will log all messages sent to all objects. The log is a written to a text file in the tmp folder. If you inspect the log file leading up to the crash, you may gain some insight into what's happening right before the crash. This is actually the technique I used to solve my bug. You can either modify your code to enable/disable logging:
instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);
Or, you can call the function directly from the debugger. For example, set a breakpoint right before the crash, then drop into the debugger console and do this:
(gdb) call (void)instrumentObjcMessageSends(YES)
Additional details are here:
http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/