泄漏 - GeneralBlock-3584

发布于 2024-07-13 11:31:17 字数 300 浏览 8 评论 0原文

当我尝试使用 Instruments 检查 iPhone 应用程序的泄漏时,一切都很好。 实际设备上的同一应用程序在应用程序启动期间多次显示此泄漏。 它是相当不确定的,并且发生在系统库中。 我试图用谷歌搜索解决方案,但没有成功。 有人遇到同样的问题吗? 有人知道解决方案吗?

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

感谢您对这个未记录问题的任何回答(不幸的是,苹果保持沉默)。

When i try to check leaks of my iPhone App using Instruments, everything is just fine.
Same App on actual real device shows this leak for a few times during the app launch. It is pretty non-deterministic and it happens in system libraries.
I tried to google down the solution without a luck.
Anyone experiencing the same problems? Anyone knows the solution?

I find interesting, that every of my leak in code will crash the app sooner or later. These GeneralBlock-3584 leaks keeps app perfectly stable.
Might this be reason for AppStore rejection?

Thanx for any answer regarding this undocumented problem (Apple is silent unfortunately).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

花伊自在美 2024-07-20 11:31:17

您无需担心,这是 Instruments 的误报。
它与释放已终止线程的资源有关。 它们只是徘徊直到下一个线程完成并清理先前终止的线程之后的资源。 仪器将此视为“泄漏”,但这是 iOS 上 pthreads 实现的一个功能,在完美的世界中会以不同的方式处理。
有关此内容的更多信息,请访问 Apple 开发论坛此处此处

You have nothing to worry about, this is false positive from Instruments.
It has to do with freeing resources of the thread that has being terminated. They just hang around until next thread is done and cleans resources after the one which is terminated previously. Instruments take this for a 'leak', but it's a feature of pthreads implementation on the iOS which in perfect world would be handled differently.
More on this on the Apple's dev forum here and here.

慢慢从新开始 2024-07-20 11:31:17

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

我对这些“泄露”的 GeneralBlock 很熟悉,根据我的经验,它们并没有导致 App Store 拒绝。

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

** 我不是 App Store 审核向导

Leak detection tools can often yield false positives, especially in underlying system libraries.

I am familiar with these "leaked" GeneralBlocks, and they didn't cause an App Store rejection in my experience.

IANAASRW**, but I think you're fine.

** I am not an App Store Review Wizard

记忆里有你的影子 2024-07-20 11:31:17

苹果框架存在漏洞。 特别是 HTTP 类。 您应该提出雷达缺陷报告。

There are leaks in the Apple frameworks. Specifically the HTTP classes. You should raise a radar defect report.

韵柒 2024-07-20 11:31:17

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

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

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

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

所以,它很可能什么都不是。 如果您可以确认访问“设置”已将其清除,那么我们就会知道从哪里开始寻找泄漏(或指示苹果去哪里寻找)。

Do you have UserDefaults that you hadn't gone into Settings to initialize during those, "first few times," you ran your app?

I saw the same problem - app was (relatively) clean on the latest Xcode/Simulator (the usual pair of 128 byte mallocs were there - but that's purely a Simulator problem with UIViews). Once I ran it on an iPod Touch, I saw the GB3584.

However, after going into Settings and changing a setting (which forced the save*), the problem went away.

  • I am using Apple's sample code for UserDefaults to properly read those settings without having to first go in and change something.

So, it may very well be nothing. If you can confirm that a visit to Settings cleared it up, then we'll know where to start looking for leaks (or where to direct Apple to look).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文