UIApplicationMain的EXC_BAD_ACCESS - 如何解释这个回溯?

时间:2011-06-25 13:46:43

标签: ios debugging crash exc-bad-access

#0  0x0149609b in objc_msgSend ()
#1  0x06a75960 in ?? ()
#2  0x0108df9a in _performRunLoopAction ()
#3  0x0131189b in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#4  0x012a66e7 in __CFRunLoopDoObservers ()
#5  0x0126f1d7 in __CFRunLoopRun ()
#6  0x0126e840 in CFRunLoopRunSpecific ()
#7  0x0126e761 in CFRunLoopRunInMode ()
#8  0x01c871c4 in GSEventRunModal ()
#9  0x01c87289 in GSEventRun ()
#10 0x00393c93 in UIApplicationMain ()
#11 0x00001f68 in main (argc=1, argv=0xbffff028) at /Users/Stu/Documents...

我对靠近顶部的?? ()感到有些困惑。看到此错误出现在第int retVal = UIApplicationMain(argc, argv, nil, nil);行时,我认为存在与自动释放池有关的内存访问问题,但到目前为止我还没有找到任何问题。

当我调用要删除某个属性的CoreData对象时,会发生错误。此过程采用NSDate对象,查找具有该日期的核心数据对象作为其“时间戳”,并删除该对象。

我启用了NSZombie和NSDebug以及MallocStackLogging,但是日志中没有显示任何信息(当然我请求它时的回溯除外)。单步执行代码也无助于缩小问题范围。

2 个答案:

答案 0 :(得分:2)

导致EXC_BAD_ACCESS的objc_msgSend()通常意味着目标对象中没有实现某个函数。我们还可以看到正在进行Observer回调。我冒昧地猜你在某处叫做-addObserver:selector:name:object:用错误的选择器。 (通常在堆栈跟踪之前打印)。

答案 1 :(得分:2)

问题解决了。

正如我最初推测的那样,确实与自动释放池有关(总是相信你的直觉......)。出于某些奇怪的原因 - 可能在没有睡了36个小时之后 - 我已经自动释放了一个没有业务被自动释放的对象。它只是一个简单的自定义getter样式方法,它返回当前选中的文本对象。

不确定为什么没有为它创建NSZombie ...