How can you solve a KERN_PROTECTION_FAILURE and a KERN_INVALID ADDRESS?
Both seem to happen at exactly the same spot when I run my app.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x6d783f44
Crashed Thread: 2
Thread 2 Crashed:
0 libobjc.A.dylib 0x34a80464 objc_msgSend + 16
1 Foundation 0x31171dda __+[__NSOperationInternal _observeValueForKeyPath:ofObject:changeKind:oldValue:newValue:indexes:context:]_block_invoke_7 + 10
2 libSystem.B.dylib 0x30dd9678 _dispatch_call_block_and_release + 12
3 libSystem.B.dylib 0x30dd9b98 _dispatch_worker_thread2 + 120
4 libSystem.B.dylib 0x30d7e24a _pthread_wqthread + 258
5 libSystem.B.dylib 0x30d76970 start_wqthread + 0
And:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000011
Crashed Thread: 7
Thread 7 Crashed:
0 libobjc.A.dylib 0x34a80464 objc_msgSend + 16
1 Foundation 0x31171dfc -[NSOperation completionBlock] + 16
2 Foundation 0x31171dda __+[__NSOperationInternal _observeValueForKeyPath:ofObject:changeKind:oldValue:newValue:indexes:context:]_block_invoke_7 + 10
3 libSystem.B.dylib 0x30dd9678 _dispatch_call_block_and_release + 12
4 libSystem.B.dylib 0x30dd9b98 _dispatch_worker_thread2 + 120
5 libSystem.B.dylib 0x30d7e24a _pthread_wqthread + 258
6 libSystem.B.dylib 0x30d76970 start_wqthread + 0
Weird thing is, it crashes on an iPad 1 (iOS 4.2.1) but not on an iPad 2 (iOS 4.3.2).
Could this maybe be a problem with the iPad itself or maybe with the memory? Or is it truly a bug in my code? If so, why can't I reproduce it on the iPad 2?
EXC_BAD_ACCESS errors are typically from trying to send a message to an object that has been deallocated. In this case, it appears to be something in your NSOperation that has been released already. This is almost certainly a bug in your code. As for why it happens on one iPad and not the other, it could be that on one device the memory that used to contain your object has been reused but on the other it still has a zombie of your object.
A much more thorough explanation is here.
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 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)...
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.
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.