2011-02-09 144 views
6
Program received signal: “EXC_BAD_ACCESS”. 
[Switching to process 388] 
kill 
error while killing target (killing anyway): warning: error on line 2179 of "/SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x) 
quit 

The Debugger has exited with status 0.(gdb) 
+0

绝对是一个非常真实的问题;我已经看到了类似这样的情况,这只是关于线索的全部内容。坚强。 – bbum 2011-02-09 22:01:05

回答

23

编程接收信号: “EXC_BAD_ACCESS”。 [切换到 过程388]杀错误而杀死 目标(杀害反正):警告: 误差线2179的 “/SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-i​​nferior.c “ 在功能 ”macosx_kill_inferior_safe“:(OS /克恩) 失败(0x5x)退出

记下误差; gdb已经坠毁。这可能是由于应用程序崩溃导致的,但是这些特定消息对于调试真正的问题肯定没有用处。

而且,更有可能的是,实际的崩溃具有什么也没有与过度释放对象有关。也许如此,但可能不会。

通常情况下,当GDB以这种方式崩溃时,这是因为你抛弃了堆或堆栈的方式,gdb跳过了腐败试图弄清楚发生了什么。或者你的应用程序进入了一个状态,gdb不能再与它进行通信(这可能是这里给出的崩溃位置的情况)。

在这种情况下,有些事情尝试:

  • 使用最新的开发工具?如果不是的话,那么也应该从干净的地方重建你的应用程序。

  • 可以在模拟器和设备上重现崩溃吗?如果是这样,它可以在一个适当的调试,但不是另一个?

  • 如果您在没有调试器的情况下运行该应用程序,是否可以让它崩溃然后从设备中提取崩溃日志?

  • 在调试和非调试版本之间行为会发生变化吗?这可能会严重影响内存损坏。

  • 这是否刚刚开始发生?如果是这样,你最近改变了什么?

想到另一个把戏;

  • 尝试设置MallocScribble环境变量。这将在分配/释放时将值写入内存中,并且通常至少会导致内存损坏相关的崩溃者早期崩溃或与之不同以捕获它。
1

EXC_BAD_ACCESS通常意味着您试图访问不存在的东西了。我们需要你的堆栈转储,并可能需要一些代码来帮助你弄明白。

+0

我该怎么做? – testndtv 2011-02-09 18:57:50

+1

EXC_BAD_ACCESS仅表示有时;有时这意味着你偶然发现了内存不正常。而且,在这种情况下,调试器崩溃意味着原始应用程序中的崩溃可能不是典型的保留/释放问题。 – bbum 2011-02-09 21:13:21

+0

调试器为什么会崩溃,可能会出错的错误不是源于操作代码中的错误? – jakev 2011-02-09 21:17:35

0

引用同事“某处出错了”。

这意味着您试图访问不再有效的指针。也许你忘了保留一个对象,或者多次释放它?