在 iOS 4.0 上释放 Autoreleasepool 会崩溃(以及 4.1 上......)
我想知道什么可能导致这种情况。 我的代码中有几个使用 PerformSelectorInBackground 调用的方法。 在每个方法中,我都有一个自动释放池,它在方法开始时分配/初始化,并在方法结束时释放。
这在 iOS 3.1.3 / 3.2 / 4.2 / 4.2.1 上完美运行,但在 iOS 4.0 上会致命崩溃,并在调用 [myPool release] 后发生 EXC_BAD_ACCESS 异常。
在我注意到这种奇怪的行为之后,我正在考虑重写我的部分代码,并使我的应用程序“不太并行”,以防客户端操作系统是 4.0。
在我这样做之后,应用程序崩溃的下一个点是在 Apple 的 Reachability“框架”的 ReachabilityCallback 方法内。
好吧,现在我不太确定该怎么办。
我在线程方法中所做的事情是非常简单的 xml 解析(没有 cocoa 调用或会影响 UI 的东西)。每个方法完成后,它都会发布一条通知,协调线程会监听该通知,一旦所有并行方法完成,协调线程就会调用视图控制器等......
我完全不知道什么会导致这种奇怪的行为。特别是因为苹果代码也失败了。
非常感谢任何帮助!
谢谢, 萨姆
I'm wondering what could cause this.
I have several methods in my code that i call using performSelectorInBackground.
Within each of these methods i have an Autoreleasepool that is being alloced/initialized at the beginning and released at the end of the method.
this perfectly works on iOS 3.1.3 / 3.2 / 4.2 / 4.2.1 but it fataly crashes on iOS 4.0 with a EXC_BAD_ACCESS Exception that happens after calling [myPool release].
After I noticed this strange behaviour I was thinking about rewriting portions of my code and to make my app "less parallel" in case that the client os is 4.0.
After I did that, the next point where the app crashed was within the ReachabilityCallback-Method from Apples Reachability "Framework".
well, now I'm not quite sure what to do.
The things i do within my threaded methods is pretty simple xml parsing (no cocoa calls or stuff that would affect the UI). After each method finishes it posts a notification which the coordinating-thread listens to and once all the parallelized methods have finished, the coordinating thread calls viewcontrollers etc...
I have absolutely no clue what could cause this weird behaviour. Especially because Apples Code fails as well.
any help is greatly appreciated!
thanks,
sam
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
检测僵尸的最佳方法是:
此后,您将在控制台中获得有关您调用哪些已释放对象的信息。
The best way to detect zombies is:
After this you will have information in console on which released objects you make calls.
看来我已经解决了这个问题。
问题是,(正如你们许多人所建议的)我在调用
[NSString stringWithContentsOfURL:urlRequest encoding:NSUTF8StringEncoding error:&error];
的方法中过度释放了 NSURL 对象,我假设 < code>stringWithContentsOfURL 自动释放我作为参数传递的 NSURL 对象。
删除
urlRequest
上的版本后,问题就消失了。不过我认为不同的 iOS 版本在这方面的表现不同是很奇怪的。整个方法如下所示:
{
NSString *数据 = nil;
NSError *错误= nil;
}
Seem's like i've solved the Issue.
The Problem was, that (as many of you suggested) I've overreleased an NSURL Object within a Method which calls
[NSString stringWithContentsOfURL:urlRequest encoding:NSUTF8StringEncoding error:&error];
I assume that
stringWithContentsOfURL
autoreleases the NSURL object that i pass as a parameter.after removing the release on
urlRequest
the issue dissapeared. Still i think that it's very strange that different iOS Versions behave differently on that matter.the whole method looked like this:
{
NSString *data = nil;
NSError *error = nil;
}
听起来像是在自动释放池范围内创建的自动释放对象被释放到了不应该释放的地方。不确定为什么行为因 SDK 版本而异;一定存在导致问题的某个地方的实现差异。您是否使用“构建和分析”构建了代码?这是否表明有什么东西可能被过度释放?
Sounds like an autoreleased object created in the scope of that autorelease pool is being released somewhere it shouldn't be. Not sure why the behaviour differs with the version of the SDK; there must be an implementation difference somewhere that's causing the issue. Have you built the code using "Build and Analyze"? Does it suggest anything might be over-released?
我还注意到
performSelectorInBackground
出现了一些奇怪的行为。我可能完全错了,但就我而言,我使用了:效果更好。如果,当您使用该方法时,您需要访问主线程(例如更新 UI),您可以:
I've noticed some strange behavior with
performSelectorInBackground
also. I might be completely wrong on this, but in my case I've used:with better results. If, when you're in that method, you need to access the main thread (to update the UI for example), you can just: