XCode 分析器“Leaked Blocks”表中的条目是否暗示存在明确的泄漏？
假设我在分析器下运行我的 iPhone 应用程序，而不是查看泄露的块信息。所以我的列表顶部有多个 NSDate 行。如果我点击这些行之一，我可以向下导航到有问题的代码。
所以我想确认“泄漏块”表中的所有条目实例是否暗示那里存在真正的泄漏，需要更新/修复编码才能解决？
注意 - 我问的原因之一是我在此处发布的代码 do I have to release the NSDate in this code below? 例如来自分析器在“泄漏块”下向我提出的代码，但是代码（请参阅这篇文章）由其他人，他们告诉我这很好。
【问题讨论】：
标签： iphone xcode ios memory-leaks profiler
XCode 分析器“Leaked Blocks”表中的条目是否暗示存在明确的泄漏？
是的。
以惰性方式评估泄漏。 leaks 不能保证捕获所有泄漏，因为它实际上并没有记录所有引用 - 它只是扫描进程的内存（包括堆栈和寄存器）以查找活动分配的模式（例如指针值）。
man leaks 将为您提供实施的具体细节，WEAKNESSES 部分确认了我对您问题的回答，并举例说明了无法检测到泄漏的情况。
如果您以真正复杂的方式管理分配（例如指针算术/偏移），您实际上可以绕过系统并引入误报——不要那样做 =)
当您在 SO 发布代码并且人们告诉您它是正确的时，他们表示您发布的程序是正确的 - another 程序的一部分。也就是说，您返回的指针（链接中的newDate）未被调用者正确引用计数，或者调用者将其传递给谁。
所有仪器都会为您记录所有引用计数 - 以防静态分析返回任何问题。
具体来说，仪器会向您显示泄漏的分配/对象是在哪里创建的。
希望有帮助。
【讨论】：
-(NSDate *) dateBySettingHour:(NSInteger)hour andMinute:(NSInteger)minute 的客户端/调用者（来自引用的链接）导致了引用计数的不平衡。调用者，或者接收newDate 的调用者将分配传递给其他任何调用者。仪器可以记录对象生命周期内的每个引用计数，并记录跟踪 - 如果程序很复杂，这非常有用。