Ios 在XCode中调试：异常断点

我正在调试一个发生在后台的随机信号陷阱崩溃。这可能与某个地方的

NSManagedObjectContext

有关

除此之外，我还尝试使用异常断点对其进行调试，以至少找出它的来源。唯一的问题是崩溃/断点发生在0 objc_异常_抛出中，这对我没有帮助

我得到的数据如下所示：

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:]

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

所以我的问题是，我如何创建一个异常断点来更早地启动它自己？我试图使断点出现在崩溃前实际Objective-C代码的最后一位

< >我尝试编辑断点以共享，中断抛出，然后中断捕获，并且改变了ObjuleC，C++，和“ALL”的异常类型，没有运气。p> 如何使异常断点提前抛出

除非有办法破译我贴的密码。如果可能的话，请给我一个简短的解释，说明它的意思，以及你是如何破译它的，这样我也可以学习：）

谢谢大家

如果我让程序运行…

它一直持续到崩溃，如下所示：

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:]

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

命令打印当前堆栈跟踪

---

编辑：使用回溯

---

看起来UIDocument的

-saveToURL:forSaveOperation:completionHandler:

方法是罪魁祸首。我以前从未上过这门课，所以我帮不了太多忙。如果在代码中的任何地方调用该方法（比如从块？），也可以在那里放置断点，以防失败。

Xcode中的调试导航器没有帮助吗？即使是最高的“分辨率”？不幸的是，没有。这是我见过的最奇怪的崩溃。奇怪。有时，可以点击调试器中的“播放”按钮，框架会编写一条更有用的错误消息。但是我假设，您尝试了这个方法，调试器只是停留在崩溃线上…？我添加了一些代码来显示它在哪里崩溃。@jsksma2能够解决导致这个问题的原因吗？我也有同样的问题。这个命令是我为“调试器命令”输入的吗？如果你不想手动键入它，你当然可以这样做。我在我的问题中添加了堆栈跟踪。嗯，事情是这样的；我没有在我的代码中的任何地方使用它。但是，恐怕在处理核心数据时会自动调用该方法。我知道你说你不熟悉那种方法，但是你有什么想法吗？还有，你怎么知道那是罪魁祸首？谢谢这是一个基于痕迹的有根据的猜测。它位于调用堆栈的底部，导致引发异常。因为它是公共API，所以您可以自己调用它。