tags:

views:

551

answers:

2

I THINK this line is causing a 3.5K Byte memory leak, any ideas why? If it's not this line it could be how I have the webView setup in xib?? I have an outlet to the webView that I use in the line below. I get general Block 3584, 1024, and 512 leaks _CFURLCache and a NSCFArray leaks. Along with some help on this, can anyone tell me if Apple will kick this back, this is the last leaks/fixes I need to get this thing out the door.

[webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:[SharedClass sharedSharedClass].usersURL]]];

Then I've used the "connectedToNetwork" method found here... connectedToNetwork Code is Over Here

And it has some memory leaks, I fixed one by adding an autorelease to the line below:

    NSURLConnection *testConnection = [[[NSURLConnection alloc] initWithRequest:testRequest delegate:self] autorelease];// ADDED autorelease

Any Help will be sincerely appreciated. Thanks,

A: 

What does [SharedClass sharedSharedClass] do? There might be something leaking in that singleton.

fbrereto
the singleton is used throughout all of my views and has been in since day one, it's been very thoroughly tested. The single line above has the 3.5K leak and the other leaks comes from the reachability code I linked to.
driveguy
What about using Intstruments? That tool will give you very precise details about the line of code causing the leak.
fbrereto
+1  A: 

I would concur with fbrereto that the singleton may well be the culprit here. Have a good poke in Instruments, as it is pretty good at finding the problem.

If you are on Snow Leopard and running Xcode 3.2, run it through Clang by using the new Build and Analyze option from the Build menu. It may well be able to point out an error here.

can anyone tell me if Apple will kick this back

Apple are not going to reject your application on account of a minor memory leak. The error would have to manifest itself in a visible way (like causing a crash) before the reviewers could reject it.

Of course, there are a whole host of other reasons that your application could be rejected. In general you can expect approval if:

  • You don't break the Human Interface Guidelines. An example of this would be using one of the standard system icons for something other than its intended purpose (even if it looks ok).
  • You don't break the SDK agreement in some way (like building an emulator that can run arbitrary code).
  • You don't infringe on anyone else's copyright or assist with others doing so.
  • You follow the guidelines on the Announcements & News page on the iPhone Dev Center (they are quite pernickety about the Reachability stuff at the moment, so present appropriate errors when there is no network available).

This is based on my own experience of the whole process, so as always, your mileage may vary. Good luck!

Jamie314