如何从 OS X 错误日志诊断应用程序崩溃？
简短的问题：这个异常是什么意思？ “EXC_BAD_ACCESS (0x0001)”
完整问题：如何使用此错误日志信息（以及我在此处省略的线程详细信息）来诊断此应用程序崩溃？ （注意：我没有崩溃日志或操作系统内核方面的专业知识。）
在这种情况下，我的电子邮件客户端（Eudora）每次启动时都会立即崩溃，在没有明显的系统更改之后。
Host Name: [name of Mac]
Date/Time: 2008-09-28 14:46:54.177 -0400
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Command: Eudora
Path: /Applications/[...]/Eudora Application Folder/Eudora.app/Contents/MacOS/Eudora
Parent: WindowServer [59]
Version: 6.2.4 (6.2.4)
PID: 231
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000001
Short Q.: What does this exception mean? "EXC_BAD_ACCESS (0x0001)"
Full Q.: How can I use this error log info (and thread particulars that I omitted here) to diagnosis this app crash? (NB: I have no expertise with crash logs or OS kernels.)
In this case, my email client (Eudora) crashes immediately on launch, every time, after no apparent system changes.
Host Name: [name of Mac]
Date/Time: 2008-09-28 14:46:54.177 -0400
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Command: Eudora
Path: /Applications/[...]/Eudora Application Folder/Eudora.app/Contents/MacOS/Eudora
Parent: WindowServer [59]
Version: 6.2.4 (6.2.4)
PID: 231
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000001
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
回答你的简短问题： EXC_BAD_ACCESS 意味着非法内存访问。 这意味着程序尝试使用其虚拟地址空间之外的内存位置（粗略地说，是它从操作系统内核请求的内存区域）。 这就是 Unix 人们通常所说的“分段错误”(segfault)，以及 Windows 人们通常所说的“访问冲突”(AV) 或“一般保护错误”(GPF)。 （是的，您可能已经知道这一点。但我只是确定...）
崩溃报告是否说明了正在引用的内存地址？ 该报告是否包括调用堆栈或核心转储？ 这三个都非常有价值，尤其是核心转储，因为您可以将其加载到调试器中并从异常点重新启动程序。 如果内存地址看起来完全不正常（在虚拟地址的上半部分，或者非常接近 0，那么您就很清楚问题出在哪里）。
To answer your short question: EXC_BAD_ACCESS means an illegal memory access. This means that the program tried to use a memory location outside its virtual address space (roughly speaking, the area of memory it has requested from the OS kernel). This is what Unix people typically call a "segmentation fault" (segfault), and what Windows people typically call an "access violation" (AV) or "general protection fault" (GPF). (Yes, you probably already knew that. But I'm just making sure...)
Does the crash report say what memory address was being referenced? Does the report include the call stack or a core dump? All three are very valuable, especially the core dump as you can load it into the debugger and restart the program right from the point of the exception. And if the memory address seems totally out of whack (in the higher half of the virtual address, or very close to 0, then you have a good clue where the problem lies).
只是为了完成迈克尔的答案 - 分析崩溃日志不是你应该做的。 eudora 程序员搞砸了（或者提供 eudora 程序员用来制作 eudora 的工具的人）。 你能做的最好的事情就是将崩溃日志的全部内容复制并粘贴到邮件客户端（尝试 MAIL，因为你现在似乎无法使用 eudora，哈哈哈），然后将其发送到 [email protected] 以及对所发生情况的简短描述。 他们的工作就是找出问题所在。
Just to complete Michael's answer - analyzing the crash log is not what you are supposed to do. The eudora programmers screwed up (or the people providing the tools the eudora programmers use to make eudora). The best thing you can do is copy and paste the entire contents of the crash log in to a mail client (try MAIL, as you can't seem to use eudora, right now, hahaha), and send it to [email protected] along with a short description of what's happening. It's their job to figure out what went wrong.