xcode 执行被中断,原因:EXC_BAD_ACCESS(代码=1,地址=0xb06b9940)
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/26987227/
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
Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0xb06b9940)
提问by user83039
I'm new to lldb and trying to diagnose an error by using po [$eax class]
我是 lldb 的新手并试图通过使用来诊断错误 po [$eax class]
The error shown in the UI is:
UI中显示的错误是:
Thread 1: EXC_BREAKPOINT (code=EXC_i386_BPT, subcode=0x0)
Here is the lldb console including what I entered and what was returned:
这是 lldb 控制台,包括我输入的内容和返回的内容:
(lldb) po [$eax class]
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0xb06b9940).
The process has been returned to the state before expression evaluation.
The global breakpoint state toggle is off.
全局断点状态切换关闭。
回答by Jim Ingham
You app is getting stopped because the code you are running threw an uncaught Mach exception. Mach exceptions are the equivalent of BSD Signals for the Mach kernel - which makes up the lowest levels of the macOS operating system.
您的应用程序正在停止,因为您正在运行的代码引发了未捕获的 Mach 异常。Mach 异常相当于 Mach 内核的 BSD 信号——它构成了 macOS 操作系统的最低级别。
In this case, the particular Mach exception is EXC_BREAKPOINT
. EXC_BREAKPOINT
is a common source of confusion... Because it has the word "breakpoint" in the name people think that it is a debugger breakpoint. That's not entirely wrong, but the exception is used more generally than that.
在这种情况下,特定的马赫异常是EXC_BREAKPOINT
。 EXC_BREAKPOINT
是一个常见的混淆源......因为它的名称中有“断点”这个词,人们认为它是一个调试器断点。这并非完全错误,但异常的使用比这更普遍。
EXC_BREAKPOINT
is in fact the exception that the lower layers of Mach reports when it executes a certain instruction (a trap instruction). That trap instruction is used by lldb to implement breakpoints, but it is also used as an alternative to assert
in various bits of system software. For instance, swift uses this error if you access past the end of an array. It is a way to stop your program right at the point of the error. If you are running outside the debugger, this will lead to a crash. But if you are running in the debugger, then control will be returned to the debugger with this EXC_BREAKPOINT
stop reason.
EXC_BREAKPOINT
实际上是Mach下层在执行某条指令(陷阱指令)时报告的异常。lldb 使用该陷阱指令来实现断点,但它也用作assert
各种系统软件位的替代方法。例如,如果您访问数组的末尾,swift 会使用此错误。这是一种在出现错误时立即停止程序的方法。如果您在调试器之外运行,这将导致崩溃。但是,如果您在调试器中运行,那么控制将因此EXC_BREAKPOINT
停止原因返回给调试器。
To avoid confusion, lldb will never show you EXC_BREAKPOINT
as the stop reason if the trap was one that lldb inserted in the program you are debugging to implement a debugger breakpoint. It will always say breakpoint n.n
instead.
为避免混淆,EXC_BREAKPOINT
如果陷阱是 lldb 插入到您正在调试的程序中以实现调试器断点的陷阱,则 lldb 永远不会向您显示停止原因。它总是会说breakpoint n.n
。
So if you see a thread stopped with EXC_BREAKPOINT
as its stop reason, that means you've hit some kind of fatal error, usually in some system library used by your program. A backtrace at this point will show you what component is raising that error.
因此,如果您看到一个线程因EXC_BREAKPOINT
停止原因而停止,则意味着您遇到了某种致命错误,通常是在您的程序使用的某些系统库中。此时的回溯将向您显示引发该错误的组件。
Anyway, then having hit that error, you tried to figure out the class of the value in the eax register by calling the class method on it by running po [$eax class]
. Calling that method (which will cause code to get run in the program you are debugging) lead to a crash. That's what the "error" message you cite was telling you.
无论如何,然后遇到该错误,您尝试通过运行po [$eax class]
. 调用该方法(这将导致代码在您正在调试的程序中运行)会导致崩溃。这就是您引用的“错误”消息告诉您的。
That's almost surely because $eax
doesn't point to a valid ObjC object, so you're just calling a method on some random value, and that's crashing.
这几乎可以肯定,因为$eax
它没有指向有效的 ObjC 对象,所以您只是在某个随机值上调用一个方法,这会导致崩溃。
Note, if you are debugging a 64 bit program, then $eax is actually the lower 32 bits of the real argument passing register - $rax. The bottom 32 bits of a 64 bit pointer is unlikely to be a valid pointer value, so it is not at all surprising that calling class
on it led to a crash.
请注意,如果您正在调试 64 位程序,那么 $eax 实际上是实参传递寄存器的低 32 位 - $rax。64 位指针的底部 32 位不太可能是有效的指针值,因此调用class
它导致崩溃也就不足为奇了。
If you were trying to call class on the first passed argument (self in ObjC methods) on 64 bit Intel, you really wanted to do:
如果您尝试在 64 位 Intel 上对第一个传递的参数(ObjC 方法中的 self)调用 class,您真的想做:
(lldb) po [$rax class]
Note, that was also unlikely to work, since $rax
only holds self
at the start of the function. Then it gets used as a scratch register. So if you are any ways into the function (which the fact that your code fatally failed some test makes seem likely) $rax would be unlikely to still hold self
.
请注意,这也不太可能奏效,因为$rax
仅self
在函数开始时有效。然后它被用作临时寄存器。因此,如果您对函数有任何了解(您的代码在某些测试中致命失败的事实似乎很可能) $rax 不太可能仍然保持self
.
Note also, if this is a 32 bit program, then $eax
is not in fact used for argument passing - 32 bit Intel code passes arguments on the stack, not in registers.
另请注意,如果这是一个 32 位程序,则$eax
实际上不用于参数传递 - 32 位英特尔代码在堆栈上传递参数,而不是在寄存器中。
Anyway, the first thing to do to figure out what went wrong was to print the backtrace when you get this exception, and see what code was getting run at the time this error occurred.
无论如何,找出问题所在的第一件事就是在遇到此异常时打印回溯,并查看发生此错误时正在运行的代码。
回答by PrzygodyZKodem
I'm adding my solution, as I've struggled with the same problem and I didn't find this solution anywhere.
我正在添加我的解决方案,因为我一直在努力解决同样的问题,但我没有在任何地方找到这个解决方案。
In my case I had to run Product -> Clean Build Folder (Clean + Option key) and rebuild my project. Breakpoints and lldb commands started to work properly.
就我而言,我必须运行 Product -> Clean Build Folder(Clean + Option 键)并重建我的项目。断点和 lldb 命令开始正常工作。
回答by Gobi M
Clean project and restart Xcode worked for me.
清理项目并重新启动 Xcode 对我有用。