【问题标题】:Guide need for debugging crash log调试崩溃日志的指导需求
【发布时间】:2011-10-12 08:00:04
【问题描述】:
#0  0x345bbc98 in objc_msgSend ()
#1  0x35cd3616 in -[_PFManagedObjectReferenceQueue _processReferenceQueue:] ()
#2  0x35cd32b2 in _performRunLoopAction ()
#3  0x31458a34 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#4  0x3145a464 in __CFRunLoopDoObservers ()
#5  0x3145b75a in __CFRunLoopRun ()
#6  0x313ebec2 in CFRunLoopRunSpecific ()
#7  0x313ebdca in CFRunLoopRunInMode ()
#8  0x354d941e in GSEventRunModal ()
#9  0x354d94ca in GSEventRun ()
#10 0x36a03d68 in -[UIApplication _run] ()
#11 0x36a01806 in UIApplicationMain ()
#12 0x00002b6a in main (argc=1, argv=0x2fdff494) at /Projects/iOS_Universal/main.m:14

我如何知道哪个对象过度释放。我的应用程序使用 NSZombieEnabled 运行,也尝试了一些 gdb 命令,但没有得到任何帮助

【问题讨论】:

    标签: iphone ipad core-data nsoperation nsoperationqueue


    【解决方案1】:

    在调试器中设置MallocStackLoggingguard malloc。然后,当您的应用崩溃时,在 gdb 控制台中输入以下内容:

    (gdb) info malloc-history 0x543216
    

    将 0x543216 替换为导致崩溃的对象的地址,您将获得更有用的堆栈跟踪,它应该可以帮助您查明代码中导致问题的确切行。

    【讨论】:

      【解决方案2】:

      在异常处添加断点(Xcode 4 使这变得非常简单),然后重新运行并使您的应用程序崩溃。您很有可能会在崩溃发生时获得一个断点。从那里您可以po 各种对象,直到您点击导致调试器抱怨的对象。

      如果你有 NSZombieEnabled 并且它没有在过度释放时抛出异常,那么你可能只是在访问一个释放的对象。最好的预防措施是 nil 您释放的任何对象。

      【讨论】:

        【解决方案3】:

        这是由于从两个不同的线程即主线程和后台线程同时访问核心数据数据库

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2019-06-05
          • 1970-01-01
          • 1970-01-01
          • 2017-10-30
          • 1970-01-01
          • 2012-04-06
          • 2011-07-20
          相关资源
          最近更新 更多