#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,但是日志中没有显示任何信息(当然我请求它时的回溯除外)。单步执行代码也无助于缩小问题范围。
答案 0 :(得分:2)
导致EXC_BAD_ACCESS的objc_msgSend()通常意味着目标对象中没有实现某个函数。我们还可以看到正在进行Observer回调。我冒昧地猜你在某处叫做-addObserver:selector:name:object:用错误的选择器。 (通常在堆栈跟踪之前打印)。
答案 1 :(得分:2)
问题解决了。
正如我最初推测的那样,确实与自动释放池有关(总是相信你的直觉......)。出于某些奇怪的原因 - 可能在没有睡了36个小时之后 - 我已经自动释放了一个没有业务被自动释放的对象。它只是一个简单的自定义getter样式方法,它返回当前选中的文本对象。
不确定为什么没有为它创建NSZombie ...