I'm writing a game using Corona for a game design class and though I'm still learning, I've got most of the basics down. Right now, I have a situation where the program slows down after about two minutes or so of playing, and I'm not entirely sure why. I've already implemented code to remove all bodies which have served their purpose and I even have it set up to print a notification when each one is removed.
http://www.mediafire.com/?5fz7ru0c6euwq1k
This is the download link. Any help is greatly appreciated. Thanks!
First off, have you checked the memory usage? If the problem gradually slows down that certainly sounds like a memory leak, but you need to check the memory usage to be sure. Print out memory usage to the console like so:
print("mem "..collectgarbage("count"))
Put that in an enterFrame listener so that you can watch the memory usage continuously while your app is running.
Now once you are seeing the memory consumed by your app, the most crucial step in any sort of debugging is isolating the problem. That is, zero in on the spot in the code that causes the problem. For some problems you can rely on techniques like printing debug messages to the console, but for a memory leak your best bet is often to selectively comment out sections of the code to see what affect that has on memory.
For example, first comment out the event listeners on one screen and then check the memory usage. If the leak is gone, then you know the problem was something to do with those event listeners. If the leak is unaffected, then restore those event listeners and comment out the next possible cause of a memory leak. rinse and repeat
Once you know the exact section of code that is causing the leak, you will probably be able to see what you need to fix. If not, ask about that specific code.
Related
My application has memory issues where after a certain threshold, the application will crash.
I've been instructed to use Instruments and select the Allocation option.
However, I can never seem to get a "direct" answer to my issue, I have attached screenshots below to help describe the issue better.
The memory issues are not linked to any ViewControllers or files that I have created. Rather other libraries/frameworks which I had no idea were being used. I have been battling this issue for a few weeks, I have altered my code/implemented a variety of methods which I believed may have resolved the issue. However, no luck.
Could someone please tell me how I can combat this issue? As I cannot seem to force the memory to be released which in turn means I have this giant memory bug within my application.
Thank you.
Edit - Added a screenshot of the memory usage when viewing an image at full resolution and returning to the home screen.
A couple of thoughts:
See this answer which talks about using “Debug Memory Graph” tool featured in WWDC 2016 video Visual Debugging with Xcode. That tool is often easier to find issues than Instruments. It organizes the reference counting types by target/framework, making it much easier to sift through the results.
But if you’re dealing with non-reference counted malloced data, then Instruments is the way to go, with all the complexity that entails. But “Debug Memory Graph” is often a better first line of defense.
You said:
The memory issues are not linked to any ViewControllers or files that I have created.
Make absolutely sure that your classes aren’t any buried down there lower in the list. There will be far fewer and the sizes are smaller, so they won’t appear up at the top and they’ll be buried in the list even tho they’re likely to be the root of the problem. Frankly, if your app is running, some of your classes have to be in there somewhere. Lol.
Again, the “Debug Memory Graph” approach helps identify your own objects much more easily than Instruments.
If possible, I’d suggest running the app, returning back to some home screen where you expect stuff to have been released, and repeat that process a few times. The first time you return to a quiescent state is not very illuminating, because there’s going to be a lot of internal caching going on. But the subsequent times you exercise the app and return to that home screen, you’ll have a better example of what’s getting allocated and not released without all of this noise of stuff the OS did on the first iteration:
(Taken from WWDC 2013 Fixing Memory Issues.)
Hopefully, the “warmup” memory isn’t too dramatic, but the red area is what we often focus on, as this is what is “wasted” as we continue to use the app (resulting in eventual crashes).
Unfortunately, your allocations curve isn’t showing it drop at all, which is worrying. Now, maybe you don’t have a “home screen” to which you can return, so maybe this isn’t relevant. But even in that scenario, you should have some state in your app that you can see memory being recovered. It’s hard to say on the basis of the information provided.
You haven’t mentioned it, but confirm what debugging options you have. For example, if you have zombies turned on, you might not see memory drop back as much as it should. Often when we first encounter these sorts of issues, we start flipping on all of these debugging options, but they have an impact on the memory profile of the app. So if you’ve been turning on things like zombies or what have you, you might want to make sure you turn them back off to make sure they’re not part of the behavior you’re seeing.
I’d suggest simulating memory warnings and see if you can see memory being recovered. Make sure your code is observing and responding to memory warnings, purging memory where it can.
This is all general advice and we can’t offer specific counsel without seeing what your code is doing. I’d suggest you create a copy of your project, prune out unrelated stuff, and keep doing that until you have the smallest possible reproducible example of this unbridled memory growth. Often that process will be enough for you to diagnose the problem on your own. But we can’t pour through tons of code. We need a minimal, complete, and verifiable example of the issue.
Bottom line, “Debug Memory Graph” is often our first level of analysis. Run the app, identify what objects you expected to be released but weren’t, and go from there. Also keep an eye on how many of these objects are out there (e.g. if you see the same view controller multiple times, that’s a sign of a strong reference cycle or some circular invocation of view controllers).
Instrument just shows you overview of how your app handling memory/CPU etc. When you find something in instrument, you have to make changes in code.
Refer this: For that you should understand how stong and weak works in iOS.
Once you understand ARC in iOS. You will understand your memory leaks in your code.
Trick is :
Try to check number of objects are not getting removed from memory in instrument.
Then check code for strong reference of object and try to remove unnecessary strong references.
Hope this will help you.
I fixed the issues which I had. Just in case anyone in future experiences the same issues this is what I did:
If declared my outlets/delegates as weak
Wherever I used the keyword self in a block where XCode demanded I use self, I added either [weak self] in or [unowned self] in
Remove any instances of the word self which were not required
Added a deinit and included a print statement
Added a breakpoint where the deinit method is called
Commented out functions in my viewDidLoad method and go through each one to see which one/if one caused the issue.
No matter how long I leave the app without touching my cpu doesn't drop below 90% or so. I'm using Parse and I've narrowed it down to Bolts using up the cpu. Is this normal? Is there any way to reduce the usage?
I don't believe I have any endless loops that would cause it.
No, that is not normal, and will drain your users’ batteries. An app that does that is definitely not releasable.
It’s impossible to know how to reduce the usage without much more diagnostic info, but it’s well worth the time to track it down.
A starting point could be to pause the offending thread in the debugger while the CPU is pegged, and see what the code is doing. If it’s inside Parse, as your profile screenshot suggests, that won’t tell you much — but sometimes examining the pegged code in the debugger as it executes reveals info that Instruments does not.
I recently ported a project over to ARC as I was having trouble with crashes and actually determining the cause, whether it was leaks or retain cycles etc., Now I have ported it over, I have not done massive testing to see whether it still crashes as I have not managed to get passed the activity monitor giving me the heeby jeebies when it shows my application doing This (activity monitor profiler)
whereas in allocations tools it looks something like
That real memory usage is not even the worst of it, at one point it shot up to around 90 odd MBs, I am unsure on how to proceed as I am not 100 percent sure what to do with the information given here, Except assume that I might be dong something, very wrong, And I have also run the leaks instrument, I have a few but they are minimal, they are all in bytes.
Does anyone have an explanation? or at the very least are able to clarify what I am possibly looking at? what's the difference between real memory usage and live bytes and overall bytes? Also these results were gotten doing exactly the same actions once and then showing you at the end of it.
I have been trying to reduce the real memory usage as pre ARC conversion I was having memory warnings and silent crashes frequently, I have not run into these again after converting, but I have not done any prolonged testing as I cannot conceive of even trying when the real memory usage looks like that. Which actually looks a lot higher than before ARC...Although the live bytes does look lower post ARC...Madness!
Something that confused me for a while is that ARC - wonderful as it is - does not necessarily avoid the need for #autoreleasepool.
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html
I ran very large memory usage in an app until someone suggested:
#autoreleasepool {
// lots of allocating of objects returned from methods then discarded
} // and the closing brace of the autoreleasepool block causes their memory to be recovered here
Maybe that will help you.
A good explanation of the meaning of the various columns in the profiler is at Instruments ObjectAlloc: Explanation of Live Bytes & Overall Bytes
I've kind of a weird issue with my iOS app.
after a while my app goes low in memory so memory warning, everything seems to be fine, but when I check the memory usage I noticed that all the calls to viewDidUnload didn't free up lot of memory, so after a few click in my app, it goes again in memory warning, everything seems to be fine again, but not a lot a memory have been released, so it goes again in memory warning faster, and then it crash (after the third memory warning most of the time). this crash is random : app freeze, app leaves, my debugger says app paused, but no bad access or sigbort, no zombies.
my guess is that memory warning can't free up enough memory has it should.
(I checked all my viewDidUnload and make nil every objects that are allocated in viewDidLoad)
Any help will be usefull !
thanks a lot.
So I managed to work with my issue.
I wrote "-(void) dealloc" methode in all my controllers and check if I enter in it as I should. (on pop controller, dissmiss etc..)
Every time it didn't, I do step by step in the controller to see what was retaining my controller from beeing dealloc.
most of the time it was some property that was not in "unsafe_unretained"
delegate that was in "ASSIGN" (and should not be in assign but in unsafe_unretained)
(heritage from non-ARC project...)
I also had some strange controller with XIB that was not deallocated even if empty.
I rebuild new one step by step with copy/paste and finaly with exactly the same code, the new controller was released, with no visible difference between then !!! gnneee
at least I know how to debug that kind issues now...
I don't think there's any way to give a specific answer without more data so the best I can do is suggest that you stop guessing what might be happening with your app and learn how to measure what is actually going on. Run your app under Instruments and you'll be able to check for leaks and also actually see what classes are responsible for the most of your application's memory footprint.
You should make sure you know how to use both the Leaks instrument to identify leaked object but also the Allocations instrument to identify orphaned (but not leaked) sets of objects which should have been released or just cases where your app is not responding to memory warnings as you expected.
https://developer.apple.com/library/ios/#documentation/developertools/conceptual/InstrumentsUserGuide/AboutTracing/AboutTracing.html might be a good place to start and there are a number of tutorials available as well; http://www.raywenderlich.com/2696/how-to-debug-memory-leaks-with-xcode-and-instruments-tutorial and http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ are among the first results I saw.
Vassily,
First, if you aren't yourself releasing extra memory, the the -didReceiveMemory warning does you no good and the OS will keep asking for memory until you are killed. This sounds like it is your problem.
Second, if that isn't the problem then you are probably getting terminated due to the size of your resident memory partitions. Make sure you look at your VM allocation in Instruments. I expect the MALLOC_TINY or MALLOC_SMALL both have greater than 5 MB resident and dirty footprints. Due to the nature of small allocations these VM regions will never shrink. The only option you really have is to not create a lot of small items in the first place. This is really only something you can address by changing you code's algorithms to use less memory.
Andrew
My application keeps consuming more and more memory as seen in the Windows Task Manager and eventually crashes due to OutOfMemory. However when i check for leaks using MemoryValidator (from www.softwareverify.com) no leaks are detected. Why is this happening?
Just because there is a growing amount of memory usage doesn't mean it is necessarily 'leaking'. You could simply be accumulating a large number of live objects and/or very large ones (containing lots and lots of data).
If you can provide more information about what language(s) you are using and what the application is doing I can perhaps help out with some more specific information!
UPDATE AS PER COMMENTS
Well, you'll just want to make sure the garbage collection is happening correctly. I'd suggest the libgc library to help with that perhaps.
http://developers.sun.com/solaris/articles/libgc.html
The only other thing I could think of as being the cause of this is that you are maintaining references to the objects somewhere unintentionally so they are just piling up.