Below is the stack trace of the thread of my app which got crashed.
I have recently converted my app to ARC.
The last call is to the cxx_destruct of HomePageViewController which is rootviewcontroller of one of my tab in tabviewcontroller.
The appdelegate implemenation file is not ARC enabled for compilation so the HomePageViewController is released once its added to the tabbarviewcontroller in appdelegate file.
HomePageViewController implementation file is having ARC enabled flag for compilation.
Can someone guide me in correct direction.
0 libobjc.A.dylib 0x35bcdf2a objc_release
1 MySample 0x00096142 -[HomePageViewController .cxx_destruct] + 402
2 libobjc.A.dylib 0x35bcff3a object_cxxDestructFromClass(objc_object*, objc_class*)
3 libobjc.A.dylib 0x35bcd0ce objc_destructInstance
4 libobjc.A.dylib 0x35bcd3a2 object_dispose
5 UIKit 0x37b05c84 -[UIViewController dealloc]
6 MySample 0x00095afa -[HomePageViewController dealloc] + 218
7 libobjc.A.dylib 0x35bcd484
8 CoreFoundation 0x3801343c _CFAutoreleasePoolPop
9 UIKit 0x37a46d94 _wrapRunLoopWithAutoreleasePoolHandler
10 CoreFoundation 0x380a56ca __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
11 CoreFoundation 0x380a39bc __CFRunLoopDoObservers
12 CoreFoundation 0x380a3d12 __CFRunLoopRun
13 CoreFoundation 0x38016eb8 CFRunLoopRunSpecific
14 CoreFoundation 0x38016d44 CFRunLoopRunInMode
15 GraphicsServices 0x35ccc2e6 GSEventRunModal
16 UIKit 0x37a8e2fc UIApplicationMain
17 MySample 0x0002be98 main + 116
18 MySample 0x0000315c start +
Comment above is correct; you appear to be manually calling release on that view controller, which is disallowed with ARC. Just remove that call and you ought to be good-to-go.
Also, why did you exclude you app delegate from ARC? There shouldn't even be much code in that class, aside from the Core Data stack if you are using Core Data...
Related
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.
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.
Our app is crashing during our tests, sending a message to a deallocated UINavigationItem. I've looked using Instruments, but all the releases and retains look balanced; it looks like something is hanging onto the variable without retaining it. I'd like to find where the message is being sent from, so that I can make sure that the object stays alive long enough to receive it.
The error in the console is:
-[UINavigationItem safeValueForKey:]: message sent to deallocated instance 0x11afab80
The stack trace is:
0 CoreFoundation ___forwarding___
1 CoreFoundation _CF_forwarding_prep_0
2 UIKit -[UINavigationItemButtonViewAccessibility(SafeCategory) accessibilityTraits]
3 UIAccessibility -[NSObject(NSObjectAccessibility) accessibilityAttributeValue:]
4 UIAccessibility _copyAttributeValueCallback
5 AXRuntime _AXXMIGCopyAttributeValue
6 AXRuntime _XCopyAttributeValue
7 AXRuntime mshMIGPerform
8 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__
9 CoreFoundation __CFRunLoopDoSource1
10 CoreFoundation __CFRunLoopRun
11 CoreFoundation CFRunLoopRunSpecific
12 CoreFoundation CFRunLoopRunInMode
13 GraphicsServices GSEventRunModal
14 GraphicsServices GSEventRun
15 UIKit UIApplicationMain
16 MyApp Functional Tests main [myapp]/main.m:14
17 MyApp Functional Tests start
...but none of that is in my code. How do I find out where the message is being sent from?
Use the Command:
Shell malloc_history process_id memory
eg. Shell malloc_history process_id 0x11afab80
Enable Following for the same
1)MallocstackLogging
2) NsDebugEnabled
3)NSZombieEnabled
this will solve the problem
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.
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.