我使用simpleFTP来请求文档信息。我用仪器检测内存泄漏如下:
在调用树中,我发现内存泄漏发生在哪里:
方法“_parseListData”如下:
- (void)_parseListData
{
NSMutableArray * newEntries;
NSUInteger offset;
// We accumulate the new entries into an array to avoid a) adding items to the
// table one-by-one, and b) repeatedly shuffling the listData buffer around.
newEntries = [NSMutableArray array];
assert(newEntries != nil);
offset = 0;
do {
CFIndex bytesConsumed;
CFDictionaryRef thisEntry;
thisEntry = NULL;
assert(offset <= self.listData.length);
bytesConsumed = CFFTPCreateParsedResourceListing(NULL, &((const uint8_t *) self.listData.bytes) [offset], self.listData.length - offset, &thisEntry);
if (bytesConsumed > 0) {
........
}
我不知道如何解决这个问题。
方法“CFFTPCreateParsedResourceListing
”是一种系统方法,它会创建__NSDate
(查看第二张图片)。
这是发生内存泄漏的地方。
答案 0 :(得分:0)
CFFTPCreateParsedResourceListing
函数会将CFDictionary
返回thisEntry
变量,该变量可能包含NSDate
个对象。
代码完成后,应在CFRelease
上调用thisEntry
:
// once we're done with thisEntry
if (thisEntry) {
CFRelease(thisEntry);
}
答案 1 :(得分:0)
旧帖子,但有用的解决方案。你可以在BlackRaccoon ftp client找到答案。 根据创建者的说法,CFFTPCreateParsedResourceListing方法保留两次NSDate,要覆盖问题,添加下一个代码,请注意这里的注释: FAQ section “实际上,在WhiteRaccoon中,如果列出一个目录,你将泄漏NSDate。苹果SDK中的函数CFFTPCreateParsedResourceListing有漏洞。我试图”修补“这个,但不能保证工作。对于OS 5.1它确实有用。“
........
if (parsedBytes > 0)
{
if (listingEntity != NULL)
{
//----- July 10, 2012: CFFTPCreateParsedResourceListing had a bug that had the date over retained
//----- in order to fix this, we release it once. However, just as a precaution, we check to see what
//----- the retain count might be (this isn't guaranteed to work).
id date = [(__bridge NSDictionary *) listingEntity objectForKey: (id) kCFFTPResourceModDate];
if (CFGetRetainCount((__bridge CFTypeRef) date) >= 2)
CFRelease((__bridge CFTypeRef) date);
这对我有用