iOS应用因EXC_BAD_ACCESS而崩溃,异常断点未指向代码

时间:2018-12-11 06:15:02

标签: ios objective-c xcode exc-bad-access backtrace

我正在升级旧项目以在更新版本的iOS上运行,但是由于以下错误,我一直在启动屏幕上崩溃:

  

错误:0x7c37d3000的内存读取失败

  

线程4:EXC_BAD_ACCESS(代码= 257,地址= 0x1c7c37d309d)

要弄清楚代码在哪里,我启用了僵尸对象,并为所有异常设置了一个断点。当应用崩溃时,断点不会突出显示一段代码,而是这样做:

断点导航器的图像

Screen Shot

它说了关于libobjc.A.dyliblibc++abi.dylib的一些内容,所以我假设这不是我的代码的一部分吗?另外,单击断点并不能像人们通常所说的那样将我带到代码中。

这是lldb控制台中bt的结果(回溯):

* thread #4, stop reason = EXC_BAD_ACCESS (code=257, address=0x1c7c37d309d)
  * frame #0: 0x00000007c37d309d

我从该追溯记录中了解到,您可以确定方法或文件等,但是此输出似乎没有该内容。

如何确定此错误的确切来源?让我知道我是否应该提供其他任何东西,因为我是这个网站的新手。谢谢!

编辑:我可能应该提到应用程序在模拟器Error上与此崩溃  这是该错误的回溯记录:

> * thread #3, stop reason = signal SIGABRT   * frame #0: 0x0000000107d5cb66 libsystem_kernel.dylib`__pthread_kill + 10
>     frame #1: 0x0000000107d96080 libsystem_pthread.dylib`pthread_kill + 333
>     frame #2: 0x00000001012b7405 libclang_rt.tsan_iossim_dynamic.dylib`wrap_pthread_kill + 325
>     frame #3: 0x0000000107b09c45 libsystem_c.dylib`abort + 127
>     frame #4: 0x00000001012b669c libclang_rt.tsan_iossim_dynamic.dylib`wrap_abort + 108
>     frame #5: 0x00000001008d5c0f GiFmojo`inittls + 431
>     frame #6: 0x00000001008d5a32 GiFmojo`runtime.etext + 98
>     frame #7: 0x00000001006fe19c GiFmojo`runtime.rt0_go + 140
>     frame #8: 0x0000000107d93661 libsystem_pthread.dylib`_pthread_body + 340
>     frame #9: 0x0000000107d9350d libsystem_pthread.dylib`_pthread_start + 377
>     frame #10: 0x0000000107d92bf9 libsystem_pthread.dylib`thread_start + 13

崩溃原因的差异非常令人困惑。

编辑:这是调试导航器的屏幕截图:

screen shot

编辑:我禁用了僵尸对象,它现在在线程4和线程5之间交替出现,并且出现错误:

  

错误:0xaeb3f7600的内存读取失败

     

线程5:EXC_BAD_ACCESS(代码= 257,地址= 0x20aeb3f7693)

对于线程5。是否有原因?

3 个答案:

答案 0 :(得分:0)

嘿可能的问题是您可以使用调试反汇编选项

转到调试标签->调试工作流程->始终显示调试反汇编

并取消选中?

答案 1 :(得分:0)

尝试在“ Breackpoints”选项卡中使用“ Symbolic Breackpoint”。通常,它有助于找到应用程序崩溃的位置。希望对您有帮助enter image description here

答案 2 :(得分:0)

似乎您有内存访问错误,例如读取无法读取的位置,写入未分配(或已释放)的位置等。

有针对此类问题的调试技术,但这非常困难。

看看这个文档:Enabling the Malloc Debugging Features

如果可能,从malloc保护开始(查找错误的写操作),最后的选择是从malloc日志输出中搜索有问题的内存地址。