I currently have implemented a third party library into my XCode project. The problem is that there are memory leaks which originate from the library which I found using Instruments.
My question is is it possible to kick off the API function which is leaking in a separate thread using the autorelease pool in order for that thread to clean up after itself? This way when I need to use it again, I start the function call in a different thread? In essence my thought is that it would be garbage collecting the leaky code so that it doesn't impact the main executable.
Memory leaks will be present either in the main thread or in any other thread. What's the difference between autoreleasing a leaking memory or releasing a leaking memory?
Same effect!
Fix the leaks.
Cheers
Related
does an entry in Instruments "leaked block" during application running imply memory leak?
That is, if one is half way through using the iPhone application, where you might have some variables that have been retained but it hasn't got to the part of the application where it gets released, then do these show up as leaked blocks or not?
If the answer is that variables which have not been finished with do show up here as leaked blocks, then this would be quite confusing then if you are stopping/pausing instruments, in which case how would one run instruments in a manner whereby any leaked blocks you see are valid memory leaks? (e.g. need to kill application to end everything first and then look at instruments?)
A leak in Instruments indicates that Instruments cannot find a pointer to the allocated memory starting at any of a group of "root" pointers. Specifically, from the Memory Usage Performance Guidelines:
The Leaks instrument records all allocation events that occur in your application and then periodically searches the application’s writable memory, registers, and stack for references to any active memory blocks. If it does not find a reference to a block in one of these places, it deems the block a “leak” and displays the relevant information in the Detail pane.
So retaining something is not a leak as long as you have a pointer to it in one of your ivars, local variables or static variables. But there are ways that the Leaks instrument can get confused, and sometimes Apple has a leak in their frameworks, and sometimes Instruments has a bug.
The thing you're looking for with Leaks are steady and significant increases in the amount of leaked memory either over time or when doing specific actions. Tiny, one-time leaks are generally not worth chasing.
You should split leak testing into logical units, be it view based or functionalities based. Start from the beginning, test your initial view thoroughly, fix issues, move to next view and so on. I recommend running static analyzer before testing for leaks.
I have an iPhone app that is crashing without explanation. After reading that Autorelease pools are ill advised for iOS I went to search them out in my app and have discovered three (including one in main.m and one in a NSThread).
What exactly do I need to do to eliminate these from my code?
Thanks!
EDIT 1
I am printing, but can't see why it's crashing. Basically I start a thread which calls a method and then the app crashes. The first thing the method is set to do is to print to the console (with no values, just to show that the call worked), but it doesn't even get to that point. Very strange. Any ideas on how I could debug this?
Where did you read that autorelease pools are ill advised? I suggest you find some better sources of information.
Granted, you shouldn't be using autorelease pools haphazardly, and improper usage can cause problems, but certain situations require them. At a minimum, that one you found in main.m should be there. As should the one you found in your NSThread. It is very unlikely that they are responsible for your crash, assuming that your code is using them correctly.
When you application crashes do you get anything at all when running in debug mode? Any stack trace in the console, or log messages talking about memory warnings? Does the app crash randomly or only after performing a particular action? More information and/or code would be useful.
Autoreleases that are part of the iOS templates are not the problem. Autorelease pools are often necessary, and may not be why your app is crashing.
To address your problem
Add NSLog statements to your code to try and find out where your app is crashing
Use Instruments to detect memory problems and leaks
You may be over releasing objects. Here's an excellent Memory Management Guide.
Autorelease in main function and in new thread is required as per apple documentation. because when app launch some memory is reserved for launching the app. and if autorelease pool rempoved from the main function memory leak will be shown by simulator same in creating new thread.
Autorelease pools are required and the presence of an Autorelease pool is certainly not your problem. If your app is failing without a helpful log, try setting a breakpoint on exceptions.
http://developer.apple.com/library/mac/#documentation/IDEs/Conceptual/Xcode4TransitionGuide/Debugging/Debugging.html
I don't have any problems with my iphone app. Theres no exc_bad_access or memory issues. However I know that I haven't properly allocated and released memory. I don't know why this isn't throwing any exceptions, but it isn't. Everything works.
I don't want to overload the iphone memory though, and am aware that just because I don't release an object doesn't mean its not still using memory, but now I am quite far through my app I can't be dealing with going back through and analyzing the whole program.
Is there any way of finding pointers and their retain count or find memory being used or anything?
Thank you.
You can use the tools that come with Xcode to detect both leaks and allocated objected. From Xcode, select Run > Start with Performance Tool > Leaks. Then choose the ObjectAlloc instrument. This will display all of the objects in memory.
This will only discover used memory for active objects, but not the retain count for individually allocated objects AFAIK.
If it's not throwing any exception it's because or you are keeping the retain count >= 0.
If you are not sure if the retain counts are equals 0, and you are concerned of leaking memory, you should run the Leaks instrument (Xcode->Run->Run with performance tool->Leaks).
You can also run the static analyzer to check possible leaks or other issues on your code (Xcode->Build->Build and Analyze).
Cheers,
vfn
Another memory question on iPhone - When running the leaks application I see a number of leaks get identified, but are caused by NSFoundation or similar, rather than my application code. Where my application name is mentioned, I have obviously resolved the leak.
I assume I can ignore these and that my app will be approved, or am I reading the data incorrectly?
Also - does the application have to have zero memory leaks before it is approved?
Cheers
Memory leaks will not cause your application to be rejected unless they contribute to general instability - e.g. a leak while moving forwards/backwards between views will eventually cause your app to crash.
Thats said, there are few actual leaks in the SDK libraries so be sure to check the leak are not actually a result of something your code is doing.
Any leaks that apple finds in testing of its own stuff will get fixed (and Apple does definitely test for leaks). The frameworks are not completely leak free, but it's dangerous to assume that a problem is in the frameworks. Here are a couple things to keep in mind:
(1) If you leak an object, the entire tree of objects hanging off it will also be reported as leaks. Suppose an object of class NSPrivateWhosit that you've never heard is leaked. Does that necessarily make it Apple's problem? No, it might be something used by an instance of NSPublicClass that you leaked.
(2) If an object is allocated in Foundation and passed to you, and you retain it, then you can leak it. The backtrace of the allocation doesn't matter. What matters is the backtrace of the unbalanced retain.
Your application will get approved even with memory leaks (at least my buggy application did get approved).
I'm having a difficult time understanding where actual Leaks are happening and where they are not in my application using Instruments. I have objects which are autoreleased and not being retained afterwards.. that are showing up as leaks via Instruments. There's also a bunch of objects which are listed as leaking that don't point back to any code that I've written myself. Perhaps it's a domino effect where one of my real leaks is causing stuff within the Apple libraries to leak, but I'm reluctant to believe that is the case. What's the best way of differentiating where the real leaks are happening?
In my experience Instruments does not give false-positives for auto-released items. (these are still referenced by an auto-release pool so there's no magic difference).
With memory leaks there can indeed by a domino effect in that one culprit results in many cascading leaks. Within instruments each leak will have a time based identity so I suggest you start with the first leaks.