Getting leak in leak in [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil]

Question

Hi all,

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

Answer 1

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