objective-c 如何调试 EXC_BAD_ACCESS 错误

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/19740200/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-03 21:08:38  来源:igfitidea点击:

How to debug EXC_BAD_ACCESS bug

objective-cxcodelldb

提问by Adam Lee

I received an error

我收到一个错误

EXC_BAD_ACCESS code=2 at0xb0987654

EXC_BAD_ACCESS 代码=2 at0xb0987654

I am wondering how to print out the value at 0xb0987654?

我想知道如何打印出 0xb0987654 处的值?

回答by Jasper Blues

To debug an EXC_BAD_ACCESS, you can generally find out the where the dangling pointer is by enabling zombie objects.

要调试 EXC_BAD_ACCESS,您通常可以通过启用僵尸对象来找出悬空指针的位置。

Xcode

Xcode

Choose edit scheme, then Diagnostics tab in the Run section, then click the 'Zombie Objects' option.

选择编辑方案,然后选择“运行”部分中的“诊断”选项卡,然后单击“僵尸对象”选项。

AppCode

应用代码

Choose edit target, and add the following environment variable:

选择编辑目标,并添加以下环境变量:

NSZombieEnabled=YES

Another cause for EXC_BAD_ACCESS can be infinite recursion, which can be found by adding some logging.

EXC_BAD_ACCESS 的另一个原因可能是无限递归,可以通过添加一些日志来找到。

Update for C++:

C++ 更新:

To debug dangling pointers in C++ with the Clang compiler try using Address Sanitizer (ASAN)from Google.

要使用 Clang 编译器调试 C++ 中的悬空指针,请尝试使用Google 的Address Sanitizer (ASAN)

回答by Jim Ingham

It looks like maybe you are trying to write onto a code page or something? EXC_BAD_ACCESS is described in /usr/include/mach/exception_types.h:

看起来您可能正在尝试写入代码页或其他内容?EXC_BAD_ACCESS 在 /usr/include/mach/exception_types.h 中有描述:

#define EXC_BAD_ACCESS          1       /* Could not access memory */
            /* Code contains kern_return_t describing error. */
            /* Subcode contains bad memory address. */

And from kern_return.h:

从 kern_return.h 开始:

#define KERN_PROTECTION_FAILURE         2
            /* Specified memory is valid, but does not permit the
             * required forms of access.
             */

You can see WHERE that address is in your binary by doing:

您可以通过执行以下操作来查看该地址在二进制文件中的位置:

(lldb) image lookup -va 0xb0987654

But what you really need to figure out is who is trying to write there. If the problem is simple this might tell you what's wrong, but as Jasper suggests, this is probably some use-after-free or other such problem, and the bad actor is long gone by the time you crash. guardmalloc can also sometimes catch this sort of error (you can enable this in Xcode in the Run scheme.)

但是你真正需要弄清楚是谁试图在那里写作。如果问题很简单,这可能会告诉您出了什么问题,但正如 Jasper 所建议的那样,这可能是一些释放后使用或其他此类问题,而当您崩溃时,坏人早已消失。guardmalloc 有时也可以捕获此类错误(您可以在 Xcode 的 Run 方案中启用它。)

回答by Gison George

Identify what you did that caused the crash. Did it crash while view of a particular view controller didLoad or in a delegate method or on a particular action. That will often help to find the object that is casuing the error.

确定你做了什么导致崩溃。它是否在查看特定视图控制器 didLoad 时或在委托方法中或在特定操作中崩溃。这通常有助于找到导致错误的对象。

  • Most of the time “NSZombies” can help to identify the dead object. You can enable NSZombies by editing your scheme Product -> Edit Scheme -> Diagnostics.
  • If you still don't find the root cause then always go backwards from child view controller to parent view controller to see what object needs to be retained or what message needs to be passed properly.
  • Look into Static Analyzer and Instruments for advanced debugging.
  • 大多数时候“NSZombies”可以帮助识别死亡物体。您可以通过编辑您的方案 Product -> Edit Scheme -> Diagnostics 来启用 NSZombies。
  • 如果您仍然没有找到根本原因,那么总是从子视图控制器向后返回到父视图控制器,以查看需要保留哪些对象或需要正确传递哪些消息。
  • 查看静态分析器和仪器进行高级调试。

I hope this will help you.

我希望这能帮到您。

Regards, Gison

问候, 吉森