泄漏 - GeneralBlock-3584

时间:2009-01-25 20:46:15

标签: iphone cocoa-touch memory-leaks instruments

当我尝试使用Instruments检查我的iPhone应用程序的泄漏时,一切都很好。 实际真实设备上的相同应用程序在应用程序启动期间显示此泄漏几次。它非常不确定,它发生在系统库中。 我试图在没有运气的情况下谷歌解决方案。 有没有遇到同样问题的人?有人知道解决方案吗?

我觉得有趣的是,我的每一次代码泄漏都会使应用程序迟早崩溃。这些GeneralBlock-3584泄漏使应用程序完全稳定。 这可能是AppStore拒绝的原因吗?

Thanx关于这个无证件问题的任何答案(Apple很遗憾)。

4 个答案:

答案 0 :(得分:8)

你无需担心,这是乐器的误报。
它与释放已终止的线程的资源有关。它们只是在下一个线程完成之前一直闲逛,并在之前终止的资源之后清理资源。仪器将此视为“泄漏”,但这是iOS上pthreads实现的一个特性,在完美的世界中将以不同的方式处理。 更多关于Apple的开发论坛herehere

答案 1 :(得分:7)

泄漏检测工具通常会产生误报,尤其是在底层系统库中。

我熟悉这些“泄露”的GeneralBlocks,并且根据我的经验,它们并没有引起App Store的拒绝。

IANAASRW **,但我认为你很好。

**我不是App Store评论向导

答案 2 :(得分:0)

Apple框架中存在泄漏。特别是HTTP类。你应该提出雷达缺陷报告。

答案 3 :(得分:0)

你是否有UserDefaults,你没有进入设置初始化期间,“前几次,”你运行你的应用程序?

我看到了同样的问题 - 应用程序在最新的Xcode / Simulator上(相对)干净(通常一对128字节的mallocs在那里 - 但这纯粹是UIViews的模拟器问题)。一旦我在iPod Touch上运行它,我就看到了GB3584。

然而,在进入“设置”并更改设置(强制保存*)后,问题就消失了。

  • 我使用Apple的UserDefaults示例代码正确读取这些设置,而无需先进入并更改内容。

所以,它可能一无是处。如果您可以确认访问设置已清除,那么我们将知道从哪里开始寻找泄漏(或指示Apple查看的位置)。