为什么 Instruments 会报告此代码中的内存泄漏?
简单的问题,仪器在这里报告泄漏...
MyViewController *myVC = [[MyViewController alloc] initWithNibName:@"myView" bundle:nil];
[self.navigationController pushViewController:myVC animated:YES]; //<<<<---- !00% leak according to Instruments
[myVC release];
我知道 myVC 是由导航控制器保留的,所以我假设当视图从导航堆栈中弹出时导航控制器会释放它们?
另外,我的一个循环中还有另一个棘手的问题,静态分析器报告这里存在潜在泄漏...
//Walk through the scheduled alarms and create notifications
NSMutableArray *fireDates = [[NSMutableArray alloc] init];
for(NSDate *fireDate in fireDates) //<<<<---- Static analyzer is reporting potential leak here
{
UILocalNotification *localNotif = [[UILocalNotification alloc] init];
if (localNotif == nil)
{
[fireDates release];
return;
}
localNotif.fireDate = fireDate;
localNotif.timeZone = [NSTimeZone defaultTimeZone];
localNotif.alertBody = [NSString stringWithFormat:@"%@", alarm.Label];
localNotif.alertAction = NSLocalizedString(@"Launch", nil);
localNotif.soundName = UILocalNotificationDefaultSoundName;
localNotif.userInfo = infoDict;
localNotif.repeatInterval = NSWeekCalendarUnit;
[[UIApplication sharedApplication] scheduleLocalNotification:localNotif];
[localNotif release];
}
[fireDates release];
我是否需要以某种方式释放 fireDate?
预先感谢您的帮助!
Quick question, Instruments is reporting a leak here...
MyViewController *myVC = [[MyViewController alloc] initWithNibName:@"myView" bundle:nil];
[self.navigationController pushViewController:myVC animated:YES]; //<<<<---- !00% leak according to Instruments
[myVC release];
I understand the myVC is retained by the nav controller, so I assume the nav controller releases them when the view is popped off the nav stack?
Also, there's another tricky one in one of my loops, the static analyzer is reporting a potential leak here...
//Walk through the scheduled alarms and create notifications
NSMutableArray *fireDates = [[NSMutableArray alloc] init];
for(NSDate *fireDate in fireDates) //<<<<---- Static analyzer is reporting potential leak here
{
UILocalNotification *localNotif = [[UILocalNotification alloc] init];
if (localNotif == nil)
{
[fireDates release];
return;
}
localNotif.fireDate = fireDate;
localNotif.timeZone = [NSTimeZone defaultTimeZone];
localNotif.alertBody = [NSString stringWithFormat:@"%@", alarm.Label];
localNotif.alertAction = NSLocalizedString(@"Launch", nil);
localNotif.soundName = UILocalNotificationDefaultSoundName;
localNotif.userInfo = infoDict;
localNotif.repeatInterval = NSWeekCalendarUnit;
[[UIApplication sharedApplication] scheduleLocalNotification:localNotif];
[localNotif release];
}
[fireDates release];
Do I need to somehow release fireDate?
Thanks in advance for your help!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这些片段都很好,就像片段一样。如果没有看到完整的代码,就无法判断您是否在其他地方做了一些愚蠢的事情。你是否曾经释放过你的navigationController(可能在你的应用程序委托
-dealloc
中)?这是一次没有多大意义的泄漏,但它可能是触发第一个警告的原因。编辑:关于第二个片段,代码看起来不错(尽管快捷方式返回情况会困扰一些编码员,他们宁愿看到
break
语句)。静态分析器可能会因为条件返回中缺少[localNotif release]
(尽管它显然是不必要的)而感到困扰。These snippets are both fine, as snippets go. Without seeing your full code it's impossible to say if you don't do something silly elsewhere. Do you ever release your navigationController (in your app delegate
-dealloc
, likely)? That's a leak that doesn't mean much, but it could be what is triggering the first warning.Edit: with regards to the second snippet, the code looks fine (though the shortcut return case will bother some coders, who would rather see a
break
statement). The static analyzer may be bothered by the lack of a[localNotif release]
(even though it's obviously unnecessary) in the conditional return.在第一个片段中,泄露了什么?仪器会告诉您分配它的行,这通常不是对泄漏“负责”的行(当然,行号往往是关闭的,因为它为您提供了返回地址,而不是调用地址)。我假设是 MyViewController 被泄露,并且该仪器实际上在抱怨 alloc (查看回溯,我认为是 cmd-E)。
如果您单击内存地址旁边的箭头(您可能需要单击一下并将鼠标悬停在泄漏地址上;我不记得了),您将看到所有的 alloc/retain/release/autorelease/malloc/free /CFRetain/CFRelease 调用该地址。忽略分配之前的那些(这些是针对恰好位于同一地址的先前对象)。匹配保留和(自动)释放。您可以将自动释放与相应的(延迟的)释放相匹配,因为延迟释放将在 NSAutoreleasePool 释放时发生(这在堆栈跟踪中很明显)。寻找没有匹配(自动)释放的保留。这就是泄漏。
在第二种情况下,如果您告诉我们 Clang SA 告诉您的内容,将会有所帮助(单击左侧的小三角形,它会展开以向您显示发生泄漏的控制流)。
但我认为循环根本不会运行,因为
fireDates
是空的。In the first snippet, what is being leaked? Instruments will tell you the line where it was allocated, which is often not the line "responsible" for the leak (of course, line numbers tend to be off because it gives you the return address, not the calling address). I'm assuming it's MyViewController being leaked, and that instruments is actually complaining about alloc (look in the backtrace, cmd-E I think).
If you click on the arrow next to the memory address (you might have to click around a bit and hover over the leak address; I don't remember) you'll see all the alloc/retain/release/autorelease/malloc/free/CFRetain/CFRelease calls on that address. Ignore the ones before alloc (those are for a previous object which happened to live at the same address). Match retains and (auto)releases. You can match an autorelease with the corresponding (delayed) release, because the delayed release will happen when NSAutoreleasePool is release (which is evident in the stack trace). Look for a retain without a matching (auto)release. That's the leak.
In the second case, it helps if you tell us what Clang SA is telling you (click the little triangle on the left and it expands to show you the control-flow where the leak occurs).
But I don't think the loop runs at all, because
fireDates
is empty.