在 XCode 中调试:异常断点 [英] Debugging in XCode: Exception Breakpoints
问题描述
我正在调试一个随机的 SIGTRAP 崩溃，它只是在后台发生.这可能与某个地方的 NSManagedObjectContext 有关系.
I'm debugging a random SIGTRAP crash right now that just happens in the background. It's probably something that has to do with an NSManagedObjectContext somewhere.
除此之外，我正在尝试使用异常断点对其进行调试，以至少找出它的来源.唯一的问题是崩溃/断点发生在 0 objc_exception_throw 中，这对我没有帮助.
Besides that, I'm trying to debug it using an exception breakpoint to at least find out where it's originating from. The only problem is that the crash/breakpoint occurs in a 0 objc_exception_throw, which is no help to me.
我返回的数据如下所示:
The data I get back looks like this:
libobjc.A.dylib`objc_exception_throw:
0x32a3a960: push {r4, r5, r6, r7, lr} // breakpoint stops here
0x32a3a962: add r7, sp, #12
0x32a3a964: mov r4, r0
0x32a3a966: movs r0, #16
0x32a3a968: blx 0x32a46854 ; symbol stub for: -[NSObject isEqual:]
所以我的问题是，我怎样才能创建一个异常断点来提前启动自己?我试图让断点出现在崩溃前实际 Objective-C 代码的最后一点.
So my question is, how I can I create an exception breakpoint to initiate itself earlier? I'm trying to make the breakpoint occur in the last bit of actual Objective-C code before the crash.
我尝试编辑要共享的断点，在抛出时中断，然后在捕获时中断，并且在 Objective-C、C++ 和所有"之间更改了异常类型，但没有成功.
I have tried editing the breakpoint to be shared, break on throw, then break on catch, and have changed the type of exception between Objective-C, C++, and "all" with no luck.
如何让异常断点更早抛出?
How can I make the exception breakpoint throw earlier?
除非有办法破译我发布的代码.如果可能的话，请给我一个简短的解释它的含义，以及你是如何破译它的，这样我也可以学习这样做:)
Unless there is a way to decipher the code I posted. If that's possible, please give me a brief explanation of what it means, and how you deciphered it so I can learn to do so as well :)
谢谢大家！
如果我让程序运行...
它继续崩溃，看起来像这样:
It continues to the crash, which looks like this:
libsystem_kernel.dylib`mach_msg_trap:
0x30830ea0: mov r12, sp
0x30830ea4: push {r4, r5, r6, r8}
0x30830ea8: ldm r12, {r4, r5, r6}
0x30830eac: mvn r12, #30
0x30830eb0: svc #128
0x30830eb4: pop {r4, r5, r6, r8} // SIGTRAP throws here
0x30830eb8: bx lr
将命令bt"作为调试器命令运行时的堆栈跟踪
* thread #13: tid = 0x2337, 0x32a3a960 libobjc.A.dylib`objc_exception_throw, stop reason = breakpoint 1.1
frame #0: 0x32a3a960 libobjc.A.dylib`objc_exception_throw
frame #1: 0x340f9fee CoreData`-[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 298
frame #2: 0x341522d2 CoreData`-[NSManagedObjectContext save:] + 730
frame #3: 0x32054b02 UIKit`__84-[UIManagedDocument writeContents:toURL:forSaveOperation:originalContentsURL:error:]_block_invoke_0 + 30
frame #4: 0x34155bc0 CoreData`developerSubmittedBlockToNSManagedObjectContextPerform + 88
frame #5: 0x36e3d4b6 libdispatch.dylib`_dispatch_client_callout + 22
frame #6: 0x36e419f6 libdispatch.dylib`_dispatch_barrier_sync_f_invoke + 30
frame #7: 0x34155d42 CoreData`-[NSManagedObjectContext performBlockAndWait:] + 174
frame #8: 0x32054862 UIKit`-[UIManagedDocument writeContents:toURL:forSaveOperation:originalContentsURL:error:] + 986
frame #9: 0x3205418a UIKit`-[UIManagedDocument writeContents:andAttributes:safelyToURL:forSaveOperation:error:] + 698
frame #10: 0x32017ce4 UIKit`__block_global_4 + 68
frame #11: 0x32017c80 UIKit`__block_global_3 + 156
frame #12: 0x339c767c Foundation`-[NSFileCoordinator _invokeAccessor:thenCompletionHandler:] + 144
frame #13: 0x339c791e Foundation`__73-[NSFileCoordinator coordinateWritingItemAtURL:options:error:byAccessor:]_block_invoke_0 + 90
frame #14: 0x339c894e Foundation`-[NSFileCoordinator(NSPrivate) _invokeAccessor:orDont:thenRelinquishAccessClaimForID:] + 202
frame #15: 0x339c926c Foundation`-[NSFileCoordinator(NSPrivate) _coordinateWritingItemAtURL:options:error:byAccessor:] + 548
frame #16: 0x339c78be Foundation`-[NSFileCoordinator coordinateWritingItemAtURL:options:error:byAccessor:] + 90
frame #17: 0x32017254 UIKit`-[UIDocument _coordinateWritingItemAtURL:error:byAccessor:] + 720
frame #18: 0x320179a0 UIKit`__59-[UIDocument saveToURL:forSaveOperation:completionHandler:]_block_invoke_0 + 284
frame #19: 0x36e3e11e libdispatch.dylib`_dispatch_call_block_and_release + 10
frame #20: 0x36e41ece libdispatch.dylib`_dispatch_queue_drain$VARIANT$mp + 142
frame #21: 0x36e41dc0 libdispatch.dylib`_dispatch_queue_invoke$VARIANT$mp + 40
frame #22: 0x36e4291c libdispatch.dylib`_dispatch_root_queue_drain + 184
frame #23: 0x36e42ac0 libdispatch.dylib`_dispatch_worker_thread2 + 84
frame #24: 0x33ba7a10 libsystem_c.dylib`_pthread_wqthread + 360
frame #25: 0x33ba78a4 libsystem_c.dylib`start_wqthread + 8
查看 Matt Wilding 在他的回答评论中发布的链接！
推荐答案
您无法控制断点触发的位置.但是，一旦您到达断点，您就可以使用 bt 命令打印当前堆栈跟踪.
You don't have much control over where that breakpoint triggers. Once you've hit the breakpoint though, you can use the bt command to print the current stack trace.
<小时>使用回溯...
With the backtrace...
看起来 UIDocument 的 -saveToURL:forSaveOperation:completionHandler: 方法是罪魁祸首.我以前从未使用过这门课，所以我无能为力.如果您在代码中的任何位置调用该方法(例如从块中调用?)，您也可以在那里放置一个断点，以防止失败.
It looks like UIDocument's -saveToURL:forSaveOperation:completionHandler: method is the culprit. I've never used the class before, so I can't help too much. If you're calling that method anywhere in your code (like from a block?), you could also put a breakpoint there, in anticipation of the failure.
这篇关于在 XCode 中调试:异常断点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
