App crashes when launching after updating app via HockeyApp - objective-c

Here's the CrashReporter information:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x347c2848 __kill + 8
1 [My Application] 0x0002ec44 fatal_signal_handler (PLCrashSignalHandler.m:98)
2 libsystem_c.dylib 0x37518522 _sigtramp + 42
3 [My Application] 0x0003040a uncaught_exception_handler (PLCrashReporter.m:136)
4 CoreFoundation 0x37663984 __handleUncaughtException + 68
5 libobjc.A.dylib 0x334082ca _objc_terminate + 122
6 libc++abi.dylib 0x37f473be safe_handler_caller(void (*)()) + 70
7 libc++abi.dylib 0x37f4744a std::terminate() + 14
8 libc++abi.dylib 0x37f4881e __cxa_rethrow + 82
9 libobjc.A.dylib 0x3340822e objc_exception_rethrow + 6
10 CoreFoundation 0x375b9556 CFRunLoopRunSpecific + 398
11 CoreFoundation 0x375b93b6 CFRunLoopRunInMode + 98
12 UIKit 0x3354dda4 -[UIApplication _run] + 544
13 UIKit 0x3354b05a UIApplicationMain + 1074
14 [My Application] 0x00002a9a main (main.m:54)
15 [My Application] 0x00002a58 0x1000 + 6744
If I delete the app and then download the updated version from scratch it works fine...

This is caused by an Objective-C exception being thrown, caught by the runloop, and re-thrown, resulting in the backtrace being lost.
To debug this without changes in PLCrashReporter/HockeyApp, you could register your own exception handler via NSSetUncaughtExceptionHandler(), and log the provided stack trace via (see [-NSException callStackReturnAddresses]). You'll need to symbolicate the results manually.
As a more general solution for this class of bug, you may be able to get the original exception backtrace by using PLCrashReporter trunk, which will record the exceptions' original backtrace separately in the crash report.
However, the HockeyApp client would need to be minimally modified to support recording the extra stack trace. The text formatter included with PLCrashReporter can be used as an example -- it will format this additional stack trace as an additional named pseudo-thread.

Related

Crash on Apple Review - iOS

I had submit application several time to review.
But every time Apple tester said the application crash.
I test on my application in environment IPV4.
Totally no crash, but Apple tester said crash when launch as below.
It's the problem about IPV6? I can't test in environment IPV6.
Thank you for your resubmission. We were unable to review your app as
it crashed on launch. We have attached detailed crash logs to help
troubleshoot this issue.
Steps to reproduce:
1) Start the app on a device 2) the app attempts to launch and crashes
Next Steps
Please revise your app and test it on a device while connected to an
IPv6 network (all apps must support IPv6) to ensure it will launch
without crashing.
Date/Time: 2016-10-25 13:02:41.6759 -0700
Launch Time: 2016-10-25 13:02:40.6012 -0700
OS Version: iPhone OS 10.0.2 (14A456)
Report Version: 104
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000010014c3fc
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [0]
Triggered by Thread: 0
Filtered syslog:
None found
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 BBBApps 0x000000010014c3fc 0x1000e4000 + 427004
1 BBBApps 0x0000000100149420 0x1000e4000 + 414752
2 UIKit 0x000000018d0a342c 0x18d021000 + 533548
3 UIKit 0x000000018d2b3b70 0x18d021000 + 2698096
4 UIKit 0x000000018d2b98e0 0x18d021000 + 2722016
5 UIKit 0x000000018d2ce080 0x18d021000 + 2805888
6 UIKit 0x000000018d2b68c4 0x18d021000 + 2709700
7 FrontBoardServices 0x0000000188d898bc 0x188d4f000 + 239804
8 FrontBoardServices 0x0000000188d89728 0x188d4f000 + 239400
9 FrontBoardServices 0x0000000188d89ad0 0x188d4f000 + 240336
10 CoreFoundation 0x0000000187196278 0x1870b9000 + 905848
11 CoreFoundation 0x0000000187195bc0 0x1870b9000 + 904128
12 CoreFoundation 0x00000001871937c0 0x1870b9000 + 894912
13 CoreFoundation 0x00000001870c2048 0x1870b9000 + 36936
14 UIKit 0x000000018d09c5dc 0x18d021000 + 505308
15 UIKit 0x000000018d097360 0x18d021000 + 484192
16 BBBApps 0x00000001000ea5e4 0x1000e4000 + 26084
17 libdyld.dylib 0x00000001860a45b8 0x1860a0000 + 17848
Here the crash report from Crashlytics:
#0. Crashed: com.apple.main-thread
0 BBBApps 0x10009183c specialized AppDelegate.application(UIApplication, didFinishLaunchingWithOptions : [NSObject : AnyObject]?) -> Bool (AppDelegate.swift:39)
1 BBBApps 0x10008ecbc #objc AppDelegate.application(UIApplication, didFinishLaunchingWithOptions : [NSObject : AnyObject]?) -> Bool (AppDelegate.swift)
2 UIKit 0x19235b42c -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 400
3 UIKit 0x19256bb70 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3524
4 UIKit 0x1925718e0 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1656
5 UIKit 0x192586080 __84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke.3134 + 48
6 UIKit 0x19256e8c4 -[UIApplication workspaceDidEndTransaction:] + 168
7 FrontBoardServices 0x18e0418bc __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 36
8 FrontBoardServices 0x18e041728 -[FBSSerialQueue _performNext] + 176
9 FrontBoardServices 0x18e041ad0 -[FBSSerialQueue _performNextFromRunLoopSource] + 56
10 CoreFoundation 0x18c44e278 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
11 CoreFoundation 0x18c44dbc0 __CFRunLoopDoSources0 + 524
12 CoreFoundation 0x18c44b7c0 __CFRunLoopRun + 804
13 CoreFoundation 0x18c37a048 CFRunLoopRunSpecific + 444
14 UIKit 0x1923545dc -[UIApplication _run] + 608
15 UIKit 0x19234f360 UIApplicationMain + 208
16 BBBApps 0x10008f9d4 main (AppDelegate.swift:17)
17 libdispatch.dylib 0x18b35c5b8 (Missing)
You can use your mac to share an IPV6 network.
Open System Preferences
Option-click on the Sharing preference pane
Option-click on Internet Sharing
A Create IPv6 Only Network checkbox will appear
Check Create IPv6 Only Network (this may also be labeled Create NAT64 Network)
Select the interface to share out over (usually this will be WiFi, to allow iOS devices to connect.)
Check the box to start internet sharing
Source
Trace/BPT trap 5 is usually related to the missing shared libraries (.dylib files).
In your case the following line suggests you which one is missing:
17 libdispatch.dylib 0x18b35c5b8 (Missing)
Make sure your app has proper access to it (compiled with it) or you have included it correctly along with your app.
You can use otool (-L) command-line tool to check more details about missing dependencies.

QuartzCore - Crash in iOS8

After releasing the new version of my iOS application , I am getting the following crash frequently.
Crashed: WebThread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x80000012
This is one of the irritating crashes where stack trace didn't give any clues related to where its crashing or what causes the crash. One major thing is that this crash is only there in iOS8. Please find below the stack trace :
0 libobjc.A.dylib objc_msgSend + 5 release
1 CoreFoundation CFRelease + 600
2 QuartzCore CA::release_objects(X::List<void const*>*) + 16
3 QuartzCore -[CAAnimation dealloc] + 54
4 libobjc.A.dylib objc_object::sidetable_release(bool) + 166
5 libobjc.A.dylib (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 404
6 CoreFoundation _CFAutoreleasePoolPop + 16
7 Foundation -[NSAutoreleasePool drain] + 122
8 CFNetwork AutoAutoreleasePool::~AutoAutoreleasePool() + 24
9 CFNetwork ___ZN27URLConnectionClient_Classic18_withDelegateAsyncEPKcU13block_pointerFvP16_CFURLConnectionPK33CFURLConnectionClientCurrent_VMaxE_block_invoke_2 + 166
10 CFNetwork RunloopBlockContext::_invoke_block(void const*, void*) + 60
11 CoreFoundation CFArrayApplyFunction + 36
12 CFNetwork RunloopBlockContext::perform() + 182
13 CFNetwork MultiplexerSource::perform() + 216
14 CFNetwork MultiplexerSource::_perform(void*) + 48
Any hint would be greatly appreciated. Thanks in advance.
Most of the time, EXC_BAD_ACCESS results from sending a message to an object that has already been released. While this is harder-than-before to do under ARC, it is still possible.
The KERN_INVALID_ADDRESS part just tells you that the memory you tried to access isn't part of your app's memory space, which lends credence to the released-object-handle hypothesis.
To debug previously released objects (called "Zombie" objects), turn on NSZombies in the debugger. In XCode 7...
CMD-SHIFT- to bring up manage schemes.
Select your scheme
Select Diagnostics
Check Enable Zombie Objects
NOTE: you only want to do this on debug builds, as zombie-objects take-up a ton of memory and hurt performance overall. Still, it's an excellent debugging tool.

Cocos2d : crash with KERN_INVALID_ADDRESS in CoreFoundation

I got a crash in my app with the following crash report:
Incident Identifier: 16EF7339-4E8F-4083-9E63-9404BC0A5A3A
CrashReporter Key: 174928c573ccbe3e1a44d9bd43a33374a9833ab5
Hardware Model: iPad3,1
Process: Killer [2930]
Path: /var/mobile/Applications/81EFF1B0-3DE0-4874-B7AA-0ACA60CBB3C2/Killer.app/Killer
Identifier: Killer
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2013-01-15 20:05:27.000 +0100
OS Version: iOS 6.0.1 (10A523)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x41d58a76
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x32e8e564 _cache_getImp + 4
1 libobjc.A.dylib 0x32e8ef84 lookUpMethod + 24
2 libobjc.A.dylib 0x32e901d2 class_respondsToSelector + 26
3 CoreFoundation 0x38bac600 objectIsKindOfClass + 32
4 CoreFoundation 0x38bac358 __handleUncaughtException + 64
5 libobjc.A.dylib 0x32e93a62 _ZL15_objc_terminatev + 126
6 libc++abi.dylib 0x33844078 _ZL19safe_handler_callerPFvvE + 76
7 libc++abi.dylib 0x33844110 std::terminate() + 16
8 libc++abi.dylib 0x33845594 __cxa_rethrow + 84
9 libobjc.A.dylib 0x32e939cc objc_exception_rethrow + 8
10 CoreFoundation 0x38af2f1c CFRunLoopRunSpecific + 452
11 CoreFoundation 0x38af2d44 CFRunLoopRunInMode + 100
12 GraphicsServices 0x370a32e6 GSEventRunModal + 70
13 UIKit 0x3a2c02f4 UIApplicationMain + 1116
14 Killer 0x00063e38 main (main.m:14)
15 Killer 0x000622bc start + 36
I really have no idea about how to debug this. Should i suspect a crash in a library called by my app ? Am i responsible for this crash, where to look at then ?
Of course the line 14 in Killer main is:
int retVal = UIApplicationMain(argc, argv, nil, #"AppDelegate");
thank you very much guys
The crash log gives very little information. Anyway, I am puzzled by that:
objc_exception_rethrow
__cxa_rethrow
so it seems that there is some C++ exception handling going on. (Specifically, while handling an exception, another exception is thrown. This will cause terminate to be executed).
This might give you a hint. Are you using any C++ library?
You could also try and set NSSetUncaughtExceptionHandler but I suspect you are not able to reproduce the issue...
(Of course, it could well be some iOS SDK framework written in C++ to cause the exception, but just to check)...

Is the crashed thread the only important one in an iOS crash-report?

I'm having trouble understanding which thread's information to dig into, in a crash log I got from iTunes.
It says that Thread 16 crashed. So, do I have to examine the code inside [FreePlayMenuScene dealloc] or is there a chance that the cause is located in another thread? For example, in Thread 0 there is a mention to NSDateFormatter, which I can't understand if is relevant or not.
To ask this as a generic question, when reading crash logs, should we only examine the thread that crashed or there may be helpful information in other threads as well? Unfortunately, I couldn't find a similar question here or anywhere online.
Here's the code:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000
Crashed Thread: 16
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libicucore.A.dylib 0x3333feac udat_close + 0
1 CoreFoundation 0x37cd60d0 __CFDateFormatterDeallocate + 12
2 CoreFoundation 0x37c513ce CFRelease + 290
3 Foundation 0x354795ea -[NSDateFormatter _clearFormatter] + 22
4 Foundation 0x354a4b44 -[NSDateFormatter dealloc] + 52
5 libobjc.A.dylib 0x34b95484
6 CoreFoundation 0x37c5343c _CFAutoreleasePoolPop + 12
7 Foundation 0x35500978 __NSThreadPerformPerform + 600
8 CoreFoundation 0x37ce5680 9 CoreFoundation 0x37ce4ee4 __CFRunLoopDoSources0 + 208
10 CoreFoundation 0x37ce3cb2 __CFRunLoopRun + 642
11 CoreFoundation 0x37c56eb8 CFRunLoopRunSpecific + 352
12 CoreFoundation 0x37c56d44 CFRunLoopRunInMode + 100
13 GraphicsServices 0x345592e6 GSEventRunModal + 70
14 UIKit 0x345c32fc UIApplicationMain + 1116
15 AClockworkBrain 0x0000365a main (main.m:13)
16 AClockworkBrain 0x0000361c start + 36
...
...
Thread 16 Crashed:
0 AClockworkBrain 0x001d7cd2 -[CCScheduler unscheduleAllSelectorsForTarget:] + 126
1 AClockworkBrain 0x001ca8f8 -[CCNode unscheduleAllSelectors] + 48
2 AClockworkBrain 0x001c9526 -[CCNode cleanup] + 38
3 AClockworkBrain 0x001f1016 -[CCArray makeObjectsPerformSelector:] + 54
4 AClockworkBrain 0x001c9550 -[CCNode cleanup] + 80
5 AClockworkBrain 0x001f1016 -[CCArray makeObjectsPerformSelector:] + 54
6 AClockworkBrain 0x001c9550 -[CCNode cleanup] + 80
7 AClockworkBrain 0x001c9cf4 -[CCNode removeAllChildrenWithCleanup:] + 156
8 AClockworkBrain 0x00078ecc -[FreePlayMenuScene dealloc] (FreePlayMenuScene.m:776)
9 Foundation 0x35500e4c __NSFinalizeThreadData + 1004
10 CoreFoundation 0x37ce0f7e __CFTSDFinalize + 62
11 libsystem_c.dylib 0x37ab9128 _pthread_tsd_cleanup + 172
12 libsystem_c.dylib 0x37ab8dfe _pthread_exit + 114
13 libsystem_c.dylib 0x37ad2160 pthread_exit + 24
14 Foundation 0x35489226 +[NSThread exit] + 6
15 Foundation 0x35500696 __NSThread__main__ + 998
16 libsystem_c.dylib 0x37ac630e _pthread_start + 306
17 libsystem_c.dylib 0x37ac61d4 thread_start + 4
Thanks a lot.
Well, never say never: there's always going to be a case where one thread does something that causes another thread to throw an exception and crash. However, when that happens you usually have some kind of timing problem or race condition, and it would be rare that the troublemaking thread was always in the same place when the crash occurs. In those situations, the bad thread "sets a trap" and then the crashing thread gets caught in it.
In your case, I don't think the date formatting has anything to do with it, unless you were sharing an NSDateFormatter on multiple threads (don't, it's not thread-safe).
Since the exception is EXC_BAD_ACCESS (access an invalid memory address) and it is happening in [CCScheduler unscheduleAllSelectorsForTarget:], my guess is that a bad pointer is lurking somewhere in your Cocos2D scene graph. Maybe you added a node that got overreleased? Hard to say. In this case, it's not necessarily another thread that is at fault, but it looks like the problem was set up by some other piece of code, which cause a problem when this code stumbled onto it.
The most important is the thread that actually crashed. But keep in mind that the crash could be affected by what is happening in other threads at the time. In most cases though, only the crashed thread is relevant. I'd worry about other threads if the crash was actually related to things being done across multiple threads or if things are in multiple threads and shouldn't be.
In the log you posted, it just so happens that at the time of the crash, a date formatter was being deallocated on the main thread. Probably not at all related to the issues with your FreePlayMenuScene issue.

Crash Log - SIGTRAP - iPhone Simulator Using XCode 4.2

I have this crash issue after I upgrade using XCode 4.2. It never happened when I use 4.0.2 before. The strangest thing is that it happened intermittently, as it sometime happened and sometime it didn't. Please help me figuring out what the cause of the crash from the log below :
Interval Since Last Report: 627313 sec
Crashes Since Last Report: 59
Per-App Crashes Since Last Report: 14
Anonymous UUID: FF7C9791-6E3A-4A0C-AB83-35DE0C08166B
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
iPhone Simulator 272, iPhone OS 4.3.2 (iPhone/8H7)
iPhone Simulator 272, iPhone OS 4.3.2 (iPhone/8H7)
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x9639baa2 __semwait_signal + 10
1 libSystem.B.dylib 0x963c79c5 nanosleep$UNIX2003 + 188
2 libSystem.B.dylib 0x963c7903 usleep$UNIX2003 + 61
3 QuartzCore 0x0168549d CABackingStoreCollectBlocking + 209
4 UIKit 0x00f27e98 -[UIApplication _handleApplicationSuspend:eventInfo:] + 1719
5 UIKit 0x00f31039 -[UIApplication handleEvent:withNewEvent:] + 4127
6 UIKit 0x00f28abf -[UIApplication sendEvent:] + 71
7 UIKit 0x00f2df2e _UIApplicationHandleEvent + 7576
8 GraphicsServices 0x027f5992 PurpleEventCallback + 1550
9 CoreFoundation 0x01b9f944 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
10 CoreFoundation 0x01affcf7 __CFRunLoopDoSource1 + 215
11 CoreFoundation 0x01afcf83 __CFRunLoopRun + 979
12 CoreFoundation 0x01afc840 CFRunLoopRunSpecific + 208
13 CoreFoundation 0x01afc761 CFRunLoopRunInMode + 97
14 GraphicsServices 0x027f41c4 GSEventRunModal + 217
15 GraphicsServices 0x027f4289 GSEventRun + 115
16 UIKit 0x00f31c93 UIApplicationMain + 1160
17 XXXXXXXXXXXXXX 0x00184f69 main + 121 (main.m:14)
18 XXXXXXXXXXXXXX 0x00002af5 start + 53
There's always these little problems in certain projects whenever xcode updates. There may be a solution to this problem that doesn't involve my solution, so I would wait for other answers before using mine.
I would always just copy/paste all of my important code, organized in text documents so that I can tell what everything used to be, then I would Un-Install (after uninstalling, delete every subfolder and all leftovers of the previous version. All projects and classes) then Re-install, create new projects and copy/paste your old code. This SHOULD fix the problem, but as I said this is a hassle so see if anyone else cam come with a more specific answer to your problem.