When debugging my Swift iOS project that also contains Objective-C parts, I cannot use breakpoints otherwise the debug server crashes, logging:
Message from debugger: The LLDB RPC server has crashed. The crash log is located in
~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and
attach the most recent crash log.
I am using the latest Xcode (11.5) but this happens since a number of updates. I suspect this started to happen at the time one of the latest Xcode updates has been installed but I am not 100% sure.
I know this question can be a duplicate, so I will add as much details as I can. The log contains, at the top:
Process: lldb-rpc-server [57486]
Path: /Applications/Xcode.app/Contents/SharedFrameworks/LLDBRPC.framework/Versions/A/Resources/lldb-rpc-server
Identifier: lldb-rpc-server
Version: 2
Code Type: X86-64 (Native)
Parent Process: Xcode [44264]
Responsible: Xcode [44264]
User ID: 501
Date/Time: 2020-06-27 20:11:09.502 +0200
OS Version: Mac OS X 10.15.5 (19F101)
Report Version: 12
Bridge OS Version: 4.5 (17P5300)
Anonymous UUID: AAD489A9-72D8-BF2A-EF2C-48E06D701EBA
Sleep/Wake UUID: 4DA8CC95-35BE-4383-A87D-E24E0A2C6A42
Time Awake Since Boot: 130000 seconds
Time Since Wake: 11000 seconds
System Integrity Protection: disabled
Crashed Thread: 9 RPC packet thread for client tid 002da567 (2991463)
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [57486]
Then, I will attach the crashing thread log:
Thread 9 Crashed:: RPC packet thread for client tid 002da567 (2991463)
0 com.apple.LLDB.framework 0x0000000109aff3f2 clang::ASTReader::ReadSLocEntry(int) + 226
1 com.apple.LLDB.framework 0x000000010a68e7ca clang::SourceManager::getFileIDLoaded(unsigned int) const + 618
2 com.apple.LLDB.framework 0x000000010a358a24 clang::SourceManager::getDecomposedLoc(clang::SourceLocation) const + 148
3 com.apple.LLDB.framework 0x0000000109b1f3ab clang::ASTReader::ReadPragmaDiagnosticMappings(clang::DiagnosticsEngine&) + 1131
4 com.apple.LLDB.framework 0x0000000109b1bf89 clang::ASTReader::InitializeContext() + 969
5 com.apple.LLDB.framework 0x0000000109b1b039 clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl<clang::ASTReader::ImportedSubmodule>*) + 3833
6 com.apple.LLDB.framework 0x00000001098ca8da clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, clang::Module::NameVisibilityKind, bool) + 11034
7 com.apple.LLDB.framework 0x0000000107e00f47 swift::ClangImporter::Implementation::loadModuleClang(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >)::$_6::operator()(llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, bool) const + 311
8 com.apple.LLDB.framework 0x0000000107e00cb5 swift::ClangImporter::Implementation::loadModuleClang(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 869
9 com.apple.LLDB.framework 0x0000000107e01320 swift::ClangImporter::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 32
10 com.apple.LLDB.framework 0x0000000107d4c3f1 swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>, bool) + 881
11 com.apple.LLDB.framework 0x0000000107d7c1ab swift::ModuleFile::associateWithFileContext(swift::FileUnit*, swift::SourceLoc, bool) + 1627
12 com.apple.LLDB.framework 0x0000000107dd64a2 swift::SerializedModuleLoaderBase::loadAST(swift::ModuleDecl&, llvm::Optional<swift::SourceLoc>, llvm::StringRef, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool, bool) + 642
13 com.apple.LLDB.framework 0x0000000107dd83d4 swift::SerializedModuleLoaderBase::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 452
14 com.apple.LLDB.framework 0x0000000107f09884 swift::ASTContext::getModule(llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 244
15 com.apple.LLDB.framework 0x0000000107d4c34c swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>, bool) + 716
16 com.apple.LLDB.framework 0x0000000107d7c1ab swift::ModuleFile::associateWithFileContext(swift::FileUnit*, swift::SourceLoc, bool) + 1627
17 com.apple.LLDB.framework 0x0000000107dd64a2 swift::SerializedModuleLoaderBase::loadAST(swift::ModuleDecl&, llvm::Optional<swift::SourceLoc>, llvm::StringRef, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool, bool) + 642
18 com.apple.LLDB.framework 0x0000000107dd85dd swift::MemoryBufferSerializedModuleLoader::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 285
19 com.apple.LLDB.framework 0x0000000107f09bb5 swift::ASTContext::getModuleByName(llvm::StringRef) + 773
20 com.apple.LLDB.framework 0x0000000106edea5d lldb_private::SwiftASTContext::GetModule(lldb_private::SourceModule const&, lldb_private::Status&) + 749
21 com.apple.LLDB.framework 0x0000000106eed644 LoadOneModule(lldb_private::SourceModule const&, lldb_private::SwiftASTContext&, std::__1::weak_ptr<lldb_private::StackFrame>&, llvm::SmallVectorImpl<swift::SourceFile::ImportedModuleDesc>&, lldb_private::Status&) + 516
22 com.apple.LLDB.framework 0x0000000106eedf79 lldb_private::SwiftASTContext::PerformAutoImport(lldb_private::SwiftASTContext&, lldb_private::SymbolContext&, std::__1::weak_ptr<lldb_private::StackFrame>&, swift::SourceFile*, lldb_private::Status&) + 281
23 com.apple.LLDB.framework 0x0000000106f4f13b lldb_private::Target::GetScratchSwiftASTContext(lldb_private::Status&, lldb_private::ExecutionContextScope&, bool) + 1291
24 com.apple.LLDB.framework 0x0000000106dc233c lldb_private::ValueObject::GetScratchSwiftASTContext() + 108
25 com.apple.LLDB.framework 0x0000000106f88744 lldb_private::SwiftLanguageRuntime::GetDynamicTypeAndAddress(lldb_private::ValueObject&, lldb::DynamicValueType, lldb_private::TypeAndOrName&, lldb_private::Address&, lldb_private::Value::ValueType&) + 148
26 com.apple.LLDB.framework 0x000000010711b8ff lldb_private::SwiftLanguage::GetPossibleFormattersMatches(lldb_private::ValueObject&, lldb::DynamicValueType) + 303
27 com.apple.LLDB.framework 0x0000000106dd5654 lldb_private::FormatManager::GetPossibleMatches(lldb_private::ValueObject&, lldb_private::CompilerType, unsigned int, lldb::DynamicValueType, std::__1::vector<lldb_private::FormattersMatchCandidate, std::__1::allocator<lldb_private::FormattersMatchCandidate> >&, bool, bool, bool, bool) + 1492
28 com.apple.LLDB.framework 0x0000000106dd4a85 lldb_private::FormattersMatchData::GetMatchesVector() + 117
29 com.apple.LLDB.framework 0x0000000106de6a08 void lldb_private::TypeCategoryMap::Get<std::__1::shared_ptr<lldb_private::TypeSummaryImpl> >(lldb_private::FormattersMatchData&, std::__1::shared_ptr<lldb_private::TypeSummaryImpl>&) + 392
30 com.apple.LLDB.framework 0x0000000106dd9420 std::__1::shared_ptr<lldb_private::TypeSummaryImpl> lldb_private::FormatManager::GetCached<std::__1::shared_ptr<lldb_private::TypeSummaryImpl> >(lldb_private::FormattersMatchData&) + 448
31 com.apple.LLDB.framework 0x0000000106dd739c std::__1::shared_ptr<lldb_private::TypeSummaryImpl> lldb_private::FormatManager::Get<std::__1::shared_ptr<lldb_private::TypeSummaryImpl> >(lldb_private::ValueObject&, lldb::DynamicValueType) + 60
32 com.apple.LLDB.framework 0x0000000106dd734e lldb_private::FormatManager::GetSummaryFormat(lldb_private::ValueObject&, lldb::DynamicValueType) + 14
33 com.apple.LLDB.framework 0x0000000106dd18c3 lldb_private::DataVisualization::GetSummaryFormat(lldb_private::ValueObject&, lldb::DynamicValueType) + 51
34 com.apple.LLDB.framework 0x0000000106dbd827 lldb_private::ValueObject::UpdateFormatsIfNeeded() + 439
35 com.apple.LLDB.framework 0x0000000106dc358e lldb_private::ValueObject::CalculateSyntheticValue(bool) + 94
36 com.apple.LLDB.framework 0x0000000106dc3842 lldb_private::ValueObject::GetSyntheticValue(bool) + 34
37 com.apple.LLDB.framework 0x0000000106d2cd5d ValueImpl::GetSP(lldb_private::ProcessRunLock::ProcessRunLocker&, std::__1::unique_lock<std::__1::recursive_mutex>&, lldb_private::Status&) + 557
38 com.apple.LLDB.framework 0x0000000106d1b33b lldb::SBValue::GetSP(ValueLocker&) const + 139
39 com.apple.LLDB.framework 0x0000000106d1bf4b lldb::SBValue::GetValueType() + 187
40 lldb-rpc-server 0x00000001068a39e4 rpc_server::_ZN4lldb7SBValue12GetValueTypeEv::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 36
41 lldb-rpc-server 0x00000001068a6ce1 rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, rpc_common::RPCPacket&, bool&) + 1553
42 lldb-rpc-server 0x00000001068aa36d Packets::ProcessPackets() + 1005
43 lldb-rpc-server 0x00000001068a9e96 Packets::ReadThread() + 214
44 lldb-rpc-server 0x00000001068a9db9 Packets::RunReadThread(void*) + 9
45 libsystem_pthread.dylib 0x00007fff72ea4109 _pthread_start + 148
46 libsystem_pthread.dylib 0x00007fff72e9fb8b thread_start + 15
Only in a few cases, I can temporally solve the problem by deleting the app from the simulator / device and cleaning the project in Xcode.
I have tried the following:
I completely removed all Cocoapods related stuff from the project, and replaced Cocoapods dependencies with mostly Carthage, and a few libraries added by and with their entire source. The problem persists.
After Cocoapods deintegrate, I tried to remove all remaining entries referencing Cocoapods from the build settings.
The problem persists and it must be something project specific since I don't experience it on any other project. I even tried to attach hopper disassembler to the debug server to better follow the crash, but for the moment I have not found the root cause of the problem. Any help will be greatly appreciated.
EDIT:
After countless hours, I could at least determine a further important detail: The crash occurs only when I set the configuration to Debug, it never happens in Release. I am now changing the different build settings one by one. This is a very lengthy process because the issue is consistent only 80% of the times, meaning that a bad configuration might temporarily work. The only certainty is that it has never occurred in Release mode. Thanks for your interest and help.
This isn’t a problem with breakpoints directly, they are just the first thing that causes lldb to read the debug information for your project. The crash is coming when lldb tries to reconstruct a clang module needed to bind some ObjC classes into the swift module info. There’s not much more to be gathered from the crash report. But the lldb “types” log will show what lldb was working on at the time of the crash. To generate that log, put the command:
log enable -f /tmp/lldb-log.txt lldb types
In your ~/.lldbinit, and redo your debug session. When it crashes, file a bug with the log and the crash with http://bugs.swift.org.
It may help to unset all project breakpoints, as well as unsetting all filters and actions to thrown errors and clean up, re-compile at least once before you set new breakpoints in an updated Xcode version.
Also check if you dont have exidently set breakpoint follow-ship in the debug icons row below your source while running. Uncheck at least once and try again.
Exact same error was driving me crazy unless i did the explained steps.
now i know where changes in Xcode's breakpoint management can lead to after an proper update.
An enterprise app written in swift and having dependencies on libraries and frameworks(swift or objc) archives successfully and gives ipa successfully when archived using Xcode 7.2.1 but on Xcode 7.3 the archiving succeeds but crashes without giving an ipa with following error message,
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
ProductBuildVersion: 7D175
ASSERTION FAILURE in /Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-10183.3/IDEProducts/DVTProducts/DVTProducts/DVTProducts/DVTProductVersion.m:44
Details: bundleIdentifier should be a non-empty string, but it's an empty string
Object: <DVTProductVersion: 0x7ff47b18ac40>
Method: -initWithBundleIdentifier:version:buildNumber:name:childProducts:productCategory:
Thread: <NSThread: 0x7ff471c18210>{number = 1, name = main}
Hints: None
Backtrace:
0 -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] (in IDEKit)
1 _DVTAssertionHandler (in DVTFoundation)
2 _DVTAssertionFailureHandler (in DVTFoundation)
3 -[DVTProductVersion initWithBundleIdentifier:version:buildNumber:name:childProducts:productCategory:] (in DVTProducts)
4 +[DVTProductVersion productVersionFromArchive:withError:] (in DVTProducts)
5 -[DVTArchiveProductSource _productsFromArchives:coordinator:] (in DVTProducts)
6 __58-[DVTArchiveProductSource updateArchivesDelayedInvocation]_block_invoke (in DVTProducts)
7 -[DVTDelayedInvocation runBlock:] (in DVTFoundation)
8 -[DVTDelayedInvocation invokeIfNeeded] (in DVTFoundation)
9 -[DVTArchiveProductSource refreshProducts] (in DVTProducts)
10 +[IDEArchivesViewController revealArchive:] (in IDEProductsUI)
11 +[IDEArchivesViewController revealArchiveNotification:] (in IDEProductsUI)
12 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ (in CoreFoundation)
13 ___CFXRegistrationPost_block_invoke (in CoreFoundation)
14 _CFXRegistrationPost (in CoreFoundation)
15 ___CFXNotificationPost_block_invoke (in CoreFoundation)
16 -[_CFXNotificationRegistrar find:object:observer:enumerator:] (in CoreFoundation)
17 _CFXNotificationPost (in CoreFoundation)
18 -[NSNotificationCenter postNotificationName:object:userInfo:] (in Foundation)
19 -[NSNotificationCenter(DVTNSNotificationCenterAdditions) _dvt_postNotificationName:object:userInfo:] (in DVTFoundation)
20 __42-[IDEArchiveManager _revealArchiveAtPath:]_block_invoke (in IDEFoundation)
21 ___DVTAsyncPerformBlockOnMainRunLoop_block_invoke (in DVTFoundation)
22 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ (in CoreFoundation)
23 __CFRunLoopDoBlocks (in CoreFoundation)
24 __CFRunLoopRun (in CoreFoundation)
25 CFRunLoopRunSpecific (in CoreFoundation)
26 RunCurrentEventLoopInMode (in HIToolbox)
27 ReceiveNextEventCommon (in HIToolbox)
28 _BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox)
29 _DPSNextEvent (in AppKit)
30 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit)
31 -[DVTApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in DVTKit)
32 -[NSApplication run] (in AppKit)
33 NSApplicationMain (in AppKit)
34 0x000000010028b39b (in Xcode)
35 start (in libdyld.dylib)
abort() called
Any help is appreciated :)
A workaround was given to this bug by apple(as copy pasted below), and was fixed in Xcode 7.3.1
Hi rgh,
This is a courtesy email regarding Bug ID# 25849118.
Engineering has provided the following feedback regarding this issue:
You can workaround this issue by following these steps:
Close Xcode.
Move ~/Library/Developer/Xcode/Products to a different location.
Reopen Xcode. Attempt rearchiving.
You should then be able to put back your product directory. If the
crash still occurs, please let us know.
THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE
Bug ID #: 25849118 Bug Title: Xcode 7.3 succeeds archiving but crashes
before creation of ipa
Summary: Currently archiving with Xcode
7.2.1 without any issues. As the log suggests i have gone through all libraries, bundles and frameworks which are included as dependencies
if any of has missed setting bundle identifier. After confirming
nothing is missing it still crashes with the same issue.
Steps to Reproduce:
1. Start archiving.
2. After build succeeds and just before creation of ipa, crash.
Expected Results: IPA
Actual Results: Crash
Version: Xcode 7.3 OSX El Capitan 10.11.4 (15E65)
Notes: Tried deleting all derived data. Did try after setting missing
bundle identifier for all included dependencies(frameworks, bundles,
libraries).
Configuration: xcode 7.2.1 on the same machine succeeds.
Attachments: 'Xcode_2016-04-19-140323_Raghavendras-MacBook-Pro.crash'
was successfully uploaded.
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)...
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.