We are developing an Monotouch application with MVVMCross similar to SqliBits sample (the UINavigationCOntroller has a tab controller and inside the tab controller there is anothe navigation controller). It seems that the memory gets allocated but never released.
To reproduce this error launch the SqliBits sample with the profiler select Sessions tab and then select a day go back, select a day go back,... and then look at the memory allocation and you will see that trhe memory gets allocated but never released.
I am allowed to attach an image yet but it is fairly easy to reproduce the error.
Regards,
Dan
As an issue, this has been discussed on https://github.com/slodge/MvvmCross/issues/19
iOS only frees up Views (via View Controller ViewDidUnload method) when there is a memory shortage - within the Simulator this can be artificially created from the Hardware menu.
Beyond this, there was also a small memory leak which looks like it was caused by a reference to the ViewModel in the Action fields within the RelayCommand. It's not entirely clear to me what caused this, but adding Dispose methods to the RelayCommand which nulls this Action seems to have removed the problem (see https://github.com/slodge/MvvmCross/commit/8fc1af3fc9960445b5358daf8111f6bc9683b907)
Related
I'm using lit-element (v2.3.1) & lit-html (v1.2.1) and having a memory leak where as a result of rendering, detached DOM nodes are not cleaned by GC and the only retainers shown for them by Chrome DevTools are WeakMaps used internally by lit-html to keep track of parts:
This doesn't happen with all renders, but I have not found a difference between the templates/renders that do and do not leak. Seems almost random. But maybe I'm missing something obvious here, would be glad to hear any suggestions regarding this.
As it happens, there is a known issue with one of the web components I'm using (mwc-ripple) where it attaches event listeners to window and fails to remove them, thus, the browser keeps in memory the whole tree containing the element leading to the memory leak described.
Problem
Example use case:
I have a control which displays a status gauge. The visual status of the gauge is bound to a property of the control
The control is part of a topology graph. So depending on the topology e. g. a 100 of these controls may be displayed at once
There are several topologies. Every time you switch to another topology view the whole graph is regenerated
Question
Could this cause a memory leak and do you have to perform a manual unbind in the old topology view before you create the new one? Similar to the bindings, do you have to remove event handlers manually?
The bindings and the event handlers are inside the control. So once the control isn't accessible anymore it should be possible that it's garbage collected. So I think you don't have to do anything, but I don't know.
Thank you very much for the expertise!
If you look into the JavaDocs:
[...] All bindings in our implementation use instances of WeakInvalidationListener, which means usually a binding does not need to be disposed. But if you plan to use your application in environments that do not support WeakReferences you have to dispose unused Bindings to avoid memory leaks.
So if you use or extend the default Bindings the Garbage Collector should be able to do its work.
If you do not, be sure do implement and call Binding.dispose().
As always: If an object is no longer referenced by any other object it gets garbage collected (at some point in the future). So usually one does not need to specifically implement in this direction, as it tends to clutter the code.
I am trying to use the Observatory tab in dartium dev tools, to find a memory leak in my framework. I have made a test program here which should be viewable in js or dart. My goal is to find out where references are holding on to Massive objects, which are just wrappers around a List<double> with a million doubles in it. If I click New Client I get a new client view on the right, if I generate a bunch of Massive objects and refresh the observatory tools I see that double now takes up most of the app memory usage. If I then delete the Massive objects and wait 5 seconds for the frameworks remote garbage collection to run, then refresh the observatory tab, the doubles still occupy the same amount of memory even though they should have been GC'd (I click the GC button on the observatoy tab to, I assume, force the GC to run.) If I keep creating and deleting Massive objects in the app eventually the page crashes, typically after around 28 Massive objects have been created. My problem is finding out how to use the tools to find out where the Massive objects are still having references hold on to them. Is it possible to get find references to objects in the dev tools?
UPDATE:
I have fixed the memory leak in the test app I link too and describe above, therefore following the instructions above will not result in recreating the memory leak.
I'm currently investigating a memory leak myself. What's missing in the observatory is a way the chain from the root to the leaking object. I'm not sure if there is already an issue open for it, though. Feel free to open a new one.
We have a really strange bug in our software. Call of glXSwapBuffers will block every now and then until some X-events are sent (mouse hovering over window/keyboard events). It seems that the bug is identical to Qt QGLWidget OpenGL rendering from thread blocks on swapBuffers() which was never properly solved. We have a same kind of situation.
In our application we create a multiple number of windows because our application needs to work with multiple screens. Each of our window is basically QWidget which has a class derived from QGLWidget as its only child. Each window has its own rendering thread attached which executes OpengGL-commands.
In this setting, application just halts every now and then. It continues normally if we feed X-events to it (moving the mouse over windows/push keyboard buttons). Based on the debugger info glXSwapBuffers() blocks somewhere inside the closed driver code.
We haven't confirmed this behaviour on NVidia cards, only with AMD-cards, and it is more likely to appear when using multiple AMD-cards. This suggests that the bug may come from the GPU-drivers.
I would like to know has any other bumped into this and has somebody even managed to solve this.
I am almost finished with my first monotouch app, almost that is, but for some big problems with memory leaks. Even though I override the viewDidUnload on every view controller so that for every UI element that I create I first remove it from its superview, then call Dispose and then set it to null, the problem persists. Using Instruments is no help, it doesn't detect the memory leaks and the memory allocations doesn't point me to anything that I can track.
My app uses mainly the MPMoviePlayer to play video streams and also displays an image gallery from images loaded through http. Both operation are causing problems.
Any ideas would be very much appreciated, thanks.
The Master is right of course. Gracias Miguel. I wanted though to give a more thorough explanation of what I did, with the hope that it may help future Xamarin colleges.
1) The MPMoviePlayer stores a video buffer which is kind of sticky. What I have done is have a unique instance running on the AppDelegate an reuse this across the views that show a video. So instead of initializing the MPMoviePlayerController with an url you use the constructor with no arguments, and then set the ContentUrl property and call Play().
2) Do not rely on ViewDidUnload being called to clean up you objects, because it is not called consistently. For example I use a lot of modal view controllers and this method never got called. Memory just kept accumulating until the app crashed. Better call you clean up code directly.
3) Images were the biggest memory hug I had. Even Images inside UIImageViews that were just used as background would never get disposed. I had to specifically call the following code on each image before I could clear up the memory:
myImageView.RemoveFromSuperview();
myImageView.Image.Dispose();
myImageView.Image = null;
myImageView.Dispose();
myImageView = null;
4) Beware of the UIWebView, it can hug a lot of memory, specially if there is some kind of AJAX interaction running on the page that you are loading. Calling the following code help a little but didn't solve all the problems. Some memory leaks remain that I wasn't able to get rid off:
NSString keyStr = new NSString("WebKitCacheModelPreferenceKey");
NSUserDefaults.StandardUserDefaults.SetValueForKey(NSObject.FromObject(val), keyStr);
5) If you can, avoid using Interface Builder. On several occasions I was never able to release UI elements created on the xib files. Positioning everything by hand can be a pain but if you are using a memory intensive application creating all your view controllers in code may be the way to go.
6) Using anonymous methods as event handlers is nice and my help code readability, but on some occasions not being able to manually detach an event handler became a problem. References to unwanted object remain in memory.
7) In my UITableViewSource I was able to have a more efficient memory handling by creating the UIImages that I use to style the cells independently and then just reusing them on my GetViewForHeader and GetCell methods.
One last thing; even though instruments is not really compatible with the way monotouch is doing things using the "Memory Monitor" was a valuable tool, if you are having problem it can indeed help.
These strategies solved most of my problems. Some may be pretty obvious in hindsight but I thought it wont hurt to pass them along.
Happy Coding and long live c# on the iPhone
The UI elements are not likely the responsible ones, those barely use any memory. And calling Dispose()/nulling helps, but only a tiny bit.
The more likely source of the problem are objects like the MPMoviePlayer, the image downloading and the image rendering. You might be keeping references to those objects which prevent the GC from getting rid of them.