[NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil错误:nil]中的泄漏中泄漏 [英] Getting leak in leak in [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil]
问题描述
我在漏水 returnData = [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil];
I am having a leak in returnData= [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil];
以下是我正在使用的代码
The below is the code i am using
NSString* curl = @"https://Some Url?ticket=";
curl = [curl stringByAppendingString:self.ticket];
curl = [curl stringByAppendingString:@"&apikey=hjgajgfjaghjf&XMLString="];
curl = [curl stringByAppendingString:stringB];
curl = [curl stringByReplacingOccurrencesOfString:@"\n" withString:@""];
NSURL *finalURL = [NSURL URLWithString:curl];
NSMutableURLRequest *theRequest = [NSMutableURLRequest requestWithURL:finalURL cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:10];
[theRequest setHTTPMethod:@"POST"];
NSData* returnData= [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil];
任何人都可以告诉我为什么我在 returndata 中泄漏了吗?我发布了returndata并进行了尝试，但仍然可以得到.
Can any one tell me why i am getting the leak in returndata I relased the returndata and tried it but still i am getting.
谢谢
推荐答案
从您发布的代码来看，没有泄漏.最终返回returnData时，调用者可能会保留它而忘记释放它，但是您提供的代码片段中的所有对象都会自动释放，并会在当前运行循环结束时释放.
From the code that you've posted, there is no leak. It's possible that when you eventually return returnData, the caller might retain it and forget to release it, but all objects in the snippet of code you've provided are autoreleased and will be freed at the end of the current runloop.
我能想到的几件事:
-
您是否可能在后台线程中运行此代码(通过performSelectorInBackground:withObject:或使用显式NSThread分配)，却忘记创建并稍后在代码周围消耗NSAutoreleasePool?
Are you perhaps running this in a background thread (via performSelectorInBackground:withObject: or with an explicit NSThread allocation) and forgetting to create and later drain an NSAutoreleasePool around the code?
您可能在NSURLConnection的缓存中占用了内存.您没有提到导致您认为returnData泄漏的原因，但是如果只是该区域内存的丢失(与专门标记returnData对象的Leaks Instrument相对)，那么您可以通过清除内存来释放RAM. NSURLConnection可以显式缓存[[NSURLCache sharedURLCache] removeAllCachedResponses];
You may have memory tied up in a NSURLConnection's cache. You didn't mention what leads you to think returnData is leaked, but if it's just a loss of memory in that area (as opposed to the Leaks Instrument specifically tagging the returnData object), then you might be able to free RAM by clearing the NSURLConnection cache explicitly with something like [[NSURLCache sharedURLCache] removeAllCachedResponses];
尽管与那里的任何实际泄漏无关，但使用NSString-stringWithFormat:而不是多次调用-stringByAppendingString:来构建URL字符串会稍微更有效率.同样，所有内容都会自动释放，因此字符串处理不会泄漏，但是在下一次NSAutoreleasePool耗尽之前，您将创建更少的临时对象并减少峰值内存使用.
While not related to any real leak there, it would be slightly more efficient to build up your URL string using NSString-stringWithFormat: instead of the several calls to -stringByAppendingString:. Again, everything is autoreleased so there is no leak in the string handling, but you'd create fewer temporary objects and reduce your peak memory usage before the next NSAutoreleasePool drain.
我要寻找解决方案的第一位是此代码的调用方.奇妙的是，它保留了此方法的返回值，并且在某些时候未正确释放它.它也可以将返回值分配给保留的@property，而最终不会在-dealloc中将属性设为nil.仪器会告诉您首先分配了泄漏内存的位置，但是它无法知道泄漏的实际位置发生-当包含指针的最后一个变量被覆盖或超出范围时.
The number one place I'd look for a solution would be in the caller of this code. Odds are pretty good that it's retaining the return value of this method and not properly releasing it at some point. It could also be assigning the return to a retained @property and not eventually nil'ing the property out in -dealloc Instruments will tell you the location that leaked memory was first allocated, but it has no way of knowing where the leak actually occurred -- when the last variable which contained the pointer is overwritten or goes out of scope.
如果还没有，请尝试使用Xcode的Build and Analyze函数来编译代码.该函数运行的CLANG静态分析器通常可以找出丢失最后一个引用的位置，这比Instruments中的运行时动态分析要多.
If you haven't already, try compiling your code with Xcode's Build and Analyze function. The CLANG static analyzer run by that function can usually figured out where your last reference is lost moreso than runtime dynamic analysis in Instruments can.
祝您好运！泄漏从来都不是一件有趣的事....
Good luck with tracking this down! Leaks are never fun....
这篇关于[NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil错误:nil]中的泄漏中泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
