This question is more of a sanity check, I cannot logically explain on how this can be happening.
I have application that uses combination of WebSQL, knockout.js and Jquery Mobile UI. It's memory heavy and does have memory leaking (knockout.js and jquery Mobile Ajax navigation doesn't go together well), to the point where after 30 minutes of usage on IPad on Safari application crashes. There is not enough time to fix it all properly till the deadline (don't judge me), so we figured we would not ajax navigate by setting $.mobile.ajaxEnabled = false; every n navigation steps (~5-10), that should terminate all dominated objects and free up the memory - solve the leak. What am I now observing is even after refreshing application, (presumably) memory is still leaking as application is still crashing after prolonged use.
How can this be? How can memory still be retained after page refresh? How could I force memory to be released?
Related
I've been building a browser feature for an app which obviously works with UIWebView. I've been seeing memory jump up when the browser opens which makes sense, however i'm seeing some troubling results during a leaks profile:
The VM: JS garbage collector and VM: WebCore purgeable data just keep climbing the more I browse. Whats even worse is that when the browser is deallocated and it's web view released, these objects are still there, taking up upwards of 6 MB of memory.
I'm not sure what if i'm not handling UIWebView correctly but there seems to be an issue with this memory being held on to after the UIWebView is deallocated.
I perform some cleanup prior to the browser being deallocated as detalled in this post http://www.codercowboy.com/code-uiwebview-memory-leak-prevention/ but this doesnt seem to be making any difference.
Has anyone had this issue? Any insight would be awesome. I've seen a few questions already related to UIWebView memory issues however they don't specifically detail the results of a profile.
I'm unsure if I would immediately consider this a problem. Those VMs only start when you add a web view to your view hierarchy and load a request with it.
It may just be the OS that keeps those resources alive in case they will be used again.
I tried to replicate your code that cleans up the data and had drops of 50%.
The JS Garbage collector was always at around 3MB minimum, but had maximums of 8MB
The WebCore purgeable data was always at around 700KB
You may also consider that this may be related to bad JavaScript that continues to live because of leaks in the JavaScript code.
I have an application that uses TWebbrowser to periodically navigate to a specific URL and extract some data. The app keeps runing 24x7 and does a lot of navigation in pages.
The problem is that TWebbrowser has a well-known memory leak problem, in which every time you navigate to a new page, the memory used for the application is increased. My app can easily use more than 2GB of RAM after some time. And after navigating hundred of times an 'Out of memory' or 'Out of system resources' exception is thrown and the only way to work around it is restarting the application.
The strange thing is FASTMM never shows these leaks. When I use my app for some minutes and close it, nothing is reported.
I've been searching for a solution for this problem for years (in fact since 2007 when I wrote the first version of my application). There are some workarounds but in fact, none of them solves the problem. For me the only workaround is really to close and open the app periodically.
I already tested the SetProcessWorkingSetSize approach, but it only shrinks the memory used by the app temporarily. After some seconds, the app uses a huge amount of memory again.
I also tried EmbeddedWB, but as it descends from TWebbrowser, it's plagued by the same issue.
By the way, I can't use a simple component like IdHTTP, because I need to do some JavaScript manipulation in the website visited.
Does anyone know if is there REALLY a solution for this problem?
QC#106829 describes one possible cause of memory leaks with TWebBrowser. Accessing Document (and any other properties that are implemented via TOleControl.GetIDispatchProp or TOleControl.GetIUnknownProp) causes leaks because it calls AddRef without ever calling Release. As a workaround, you can manually call Release, or you can patch the VCL (see here), or you can avoid the problematic properties (for example, by using browser.DefaultInterface.Document instead of browser.Document).
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
is it possible, that when the iPad application is forcibly closed/killed by the iOS becuase of 'out of memory situation', the memory the application allocated is not 100% released? I think that the memory allocated directly by the client is released - there is even HW support for this, but we were observing that if the application is closed/killed by iOS and consequently started again less and less memory is available, until the iPad must be restarted. We think that some memory are allocated e.g. by background running daemons, which do some job on behalf of application and if the inter-process communication is not successfully finished, used memory on the daemon side might not be released properly...
Is something like this possible?
BR
STeN
If you alloc memory it will stay in the heap until you release it, even if the app that did the alloc is long gone. Like you have seen restarting the device will clear the heap.
You should always manage memory events, there is a method for this.
- (void)didReceiveMemoryWarning;
typically you would release everything you can, especially if its a level 2, as if you don't your app is going to close anyway.
However, When your app exits it should be calling dealloc anyway! so you may have a general leak.
I'm fairly certain that the method:
- (void)applicationWillTerminate:(UIApplication *)application;
will run even if the app is crashing. This would be a good time to ensure that everything is released, if it is not getting caught by the memoryWarning.
I am creating apps for the Ipad and its driving me crazy.
The memory that is usable by the apps changes depending on what other apps were ran before it.
There is no reliable set amount of memory that can be used by your app.
i.e. If safari is ran then even after it closes it takes up some amount of memory which effects other apps.
Does anyone know if there is a way to clear the memory before my app runs so I can get the same running environment every time?
I have created several prototype apps to show to other people and it seems like after a few days they always come back to me and tell me that it crashes and to fix it.
When I test it, the reason is always because there is not enough memory (when there was enough before when I was testing). So I need to squeeze every bit of memory (which usually effects performance due to heavy loading and releasing) out of the app and tell them to restart their ipad if it continues to happen.
I read in a book that generally apps can use at max 40mb or so, most of the apps that crash are crashing at around 27mb. I want my remaining 13mb!!
While you will get a pretty good state after a reboot, what you really should look for is clean memory management and avoiding leaks.
Using the available memory wisely is solely up to the programmer. Don't tell your users to reboot the device, ever. And with every update of the OS memory things might change anyway.