Getting leak in leak in [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];

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

---

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:

1. 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?

2. 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];

3. 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....

---

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:

[...]

curl = [curl stringByAppendingString:@"&hello=hello"];

curl = [curl stringByAppendingString:nowStr];

where nowStr:

NSDate *now = [NSDate date];

NSString * nowStr = [NSString stringWithFormat:@"%@", now];

nowStr = [nowStr stringByReplacingOccurancesOfString:@" " withString:@""];

nowStr = [nowStr stringByReplacingOccurancesOfString:@"+" withString:@""];

I am sure I should have use something to do with a random number and maybe I will do it later.