在 [NSURLConnection sendSynchronousRequest:theRequest returnedResponse:nil error:nil] 中获取泄漏
我有泄漏 returnData= [NSURLConnection sendSynchronousRequest:theRequest returnedResponse:nil error:nil];
下面是我正在使用的代码
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 中发生泄漏我释放了返回数据并尝试了它,但我仍然得到了。
谢谢
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];
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.
Thank You
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
从您发布的代码来看,没有泄漏。当您最终返回 returnData 时,调用者可能会保留它并忘记释放它,但您提供的代码片段中的所有对象都会自动释放,并将在当前运行循环结束时释放。
我能想到的一些事情:
您是否可能在后台线程中运行它(通过 PerformSelectorInBackground:withObject: 或使用显式 NSThread 分配)并忘记在代码周围创建并随后耗尽 NSAutoreleasePool?
您的内存可能被占用在 NSURLConnection 的缓存中。您没有提到是什么导致您认为 returnData 被泄漏,但如果只是该区域内存丢失(而不是 Leaks Instrument 专门标记 returnData 对象),那么您可能可以通过清除NSURLConnection 显式缓存类似于
[[NSURLCache sharedURLCache]removeAllCachedResponses];
虽然与任何实际泄漏无关,但使用
NSString 构建 URL 字符串会稍微更有效-stringWithFormat:
而不是多次调用-stringByAppendingString:
。同样,所有内容都是自动释放的,因此字符串处理中不会发生泄漏,但是您可以创建更少的临时对象,并在下一次 NSAutoreleasePool 耗尽之前减少峰值内存使用量。我寻找解决方案的第一个地方是这段代码的调用者。它很有可能保留该方法的返回值,并且在某个时候没有正确释放它。它还可以将返回值分配给保留的@property,而不是最终在-dealloc中将属性清零。仪器会告诉您泄漏内存首次分配的位置,但它无法知道泄漏实际发生在哪里——包含指针的最后一个变量何时被覆盖或超出范围。
如果您还没有这样做,请尝试使用 Xcode 的构建和分析功能编译您的代码。由该函数运行的 CLANG 静态分析器通常比 Instruments 中的运行时动态分析更能找出最后一个引用丢失的位置。
祝你追踪成功!泄漏从来都不是一件有趣的事......
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.
A few things I can think of:
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?
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];
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.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.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....
我遇到了相反的问题。我无法让它清除缓存。所以这就是我所做的:我添加了另一对,它总是不同的,使得 URL 总是有点不同。我补充道:
我确信我应该使用一些与随机数有关的东西,也许我稍后会这样做。
I had the reverse of the problem. I could not get it to clear the cache. So here is what I did: I added yet another pair which will always be different making the URL always a bit different. I added:
I am sure I should have use something to do with a random number and maybe I will do it later.