release ipa: how to symbolicate my classes' calls in a stack trace? Framework calls are shown - objective-c

My app is written both in objective c and c++. I'm using xcode 4.5 and of course I have developer account, my device is not jailbroken and I've set up everything in my developer account ok.
I do not use "Device Logs" from xcode, instead I've implemented signals/exceptions handlers to write stack traces to file and - when next time app launches - send it to my webserver.
To get stack trace on crash I use [NSException callStackSymbols]. It works. So when I do sample crash like:
NSArray *arr=[NSArray array];
[arr objectAtIndex:100];
while debugging in xcode and launching installed from xcode app on device I get:
0 CoreFoundation 0x36c738a7 __exceptionPreprocess + 186
1 libobjc.A.dylib 0x3308a259 objc_exception_throw + 32
2 CoreFoundation 0x36bcb23d -[__NSArrayI objectAtIndex:] + 164
3 MyApp 0x001be505 _ZN8Menu6handleEN12GestureE + 912
4 MyApp 0x000e6ce1 _ZN13BaseLevel10handleBaseEN12GestureE + 440
5 MyApp 0x0011b747 _ZN12Manager6handleEN12GestureE + 742
6 MyApp 0x00102731 _ZN13Processor9doProcessEd + 552
7 GLKit 0x3723a0c5 -[GLKViewController _updateAndDraw] + 272
8 CoreFoundation 0x36bd27d3 -[NSObject performSelector:] + 38
9 QuartzCore 0x3233486f _ZN2CA7Display11DisplayLink8dispatchEyy + 166
10 QuartzCore 0x323347c5 _ZN2CA7Display16IOMFBDisplayLink8callbackEP21__IOMobileFramebufferyyyPv + 60
MyApp c++ and objc classes and methods are symbolicated ok.
But when I make AdHoc ipa, and do the same crach in it I get:
0 CoreFoundation 0x36c738a7 __exceptionPreprocess + 186
1 libobjc.A.dylib 0x3308a259 objc_exception_throw + 32
2 CoreFoundation 0x36bcb23d -[__NSArrayI objectAtIndex:] + 164
3 MyApp 0x001be505 _mh_execute_header + 894213
4 MyApp 0x000e6ce1 _mh_execute_header + 11489
5 MyApp 0x0011b747 _mh_execute_header + 227143
6 MyApp 0x00102731 _mh_execute_header + 124721
7 GLKit 0x3723a0c5 -[GLKViewController _updateAndDraw] + 272
8 CoreFoundation 0x36bd27d3 -[NSObject performSelector:] + 38
9 QuartzCore 0x3233486f _ZN2CA7Display11DisplayLink8dispatchEyy + 166
10 QuartzCore 0x323347c5 _ZN2CA7Display16IOMFBDisplayLink8callbackEP21__IOMobileFramebufferyyyPv + 60]
i.e. names of my classes and methods are gone, replaced by symbol _mh_execute_header+<offset>.
I thought I've missed dSYM setting, but it is on for both release and debug, also "strip debug symbols" is off.
Have searched on SO, but no luck. Please tell me what's wrong?

My bad, I was not familar with symbolicate techs.
In short - to symbolicate stack trace you need dSYM of package and xcode to symbolicate the crash log with its private api. Maybe next time I'll write more: still learning how to do it in the most convenient (for me) way.
Edit: a week has passed, and I've developed a solution. It's specific to my multiplatform ecosystem, but here how it works in short. App crashes and sends crash log with all needed data to my server. When I want to see crash logs, I launch utility on my desktop which downloads all the stacks (from release/arm binaries) from the server, which are not proccessed yet. Next it finds corresponding bundles in Xcode Archives folder (gets uuids/vmaddr for arch needed), then calculates real addresses of stack lines (using binary vmaddr and _mh_execute_header address from received log) and calls atos for every address. Then it parses output of atos, generate diff and sends it back to server. This way I can see symbolicated stacks in my php-based bugtracker.
It was not so easy, as getting deobfuscated stacks in java, but still it's possible.

You can use this Symbolication tool I wrote to quickly Symbolicate your app's addresses.
symbolication your.app.dSYM your.app.trace
The symbolicated version will be printed to STDOUT. For best results, keep your .app in the same folder as your .dSYM.
https://github.com/Imperiopolis/Symbolication

Related

In only one of my projects, I cannot at all use the Xcode breakpoints, lldb crashes with always the same log. Is there any way to debug the issue?

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.

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.

How do I find out where a message is being sent from?

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

App crashes when launching after updating app via HockeyApp

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.