I have test application:
http://www.mediafire.com/download/y5nxo6esifys4h0/LeakMemLLS.rar
It consists of 2 pages:
Main Page.
ListItems Page (use LongListSelector).
When I go to ListItems page and back to Main page many time. The memory is increase.
Does anybody know what is the problem?
Thanks.
When you navigate back from PhoneApplicationPage, and then again to it, runtime create a new instance of it. Therefore this memory increase you see. Usually it's okay, since garbage collector will reclaim the unused instances when it will be necessary.
You have to clear stack every time when reach onNavigateTo() of any page,all pages are maintain in stack and GC.Colect() can not remove your stack.
int a = NavigationService.BackStack.Count();
while (a > standerdCount)
{
this.NavigationService.RemoveBackEntry();
a = NavigationService.BackStack.Count();
}
standerdCount is stack count when app reach to page first time.
Alternatively you can use NavigationService.GoBack() when navigate from ListItem Page to MainPage.
Related
I am using a tree within the left panel and a detail view (VerticalLayout with labels and buttons) within the right panel. Each node contains extensive data, that are saved by this way:
IndexedContainer nodeData;
.
.
.
tree.getContainerDataSource()
.getContainerProperty(itemId, "nodeData").setValue(nodeData)
The content for selected node is displayed in detail view. It can be modified using a modal window (clicking "Edit" button in detail view).
I am using nodeData.addValueChangeListener(detailView). The detail view implements function for updating its own content when the modal window saves nodeData. It works fine, but I have worries about memory leak. The right panel content (detailView) is destroyed when I select another node. Another view can be placed on the same place, because the nodeData of another node can have another structure. But nodeData container lives for long time and I can select it more times. My question is: Does it cause memory leak? Or the system is able to remove unaccessible object that are referenced only as a listener?
Thank you for telling me, if it can be problem. Any advices are appreciated.
I wouldn't worry about a memory leak in this case, as the listener is being injected into the component.
You can detect if there is a memory leak or not from the server, for instance, stopping Tomcat server will through some memory leak errors in the logs if there is a memory leak or any unreachable objects.
However, I would recommend overriding the detach() method on your tree to make sure you cleanup your resources once a view or a component is detached from the screen/view.
The problem is solved. It is possible to check out the component from listening changes, when it is orphaned:
if(!isAttached())
nodeData.removeValueChangeListener(this);
You can view the simple testing page here
The page contains one textarea, a "create" button and a "remove" button.
When the "create" button is clicked, the "textarea" is used to create "wysihtml5".
When the "remove" button is clicked, the "wysihtml5" is removed with the code below:
$("iframe.wysihtml5-sandbox, input[name='_wysihtml5_mode']").remove();
$("body").removeClass("wysihtml5-supported");
(Please refer to this for reference.)
The problem I am having is that the memory of the elements(textarea, iframe, and links) created by wysihtml5 seem to be retained in the memory.
I take few heap snap shots with google chrome dev tool.
snap1 - when the page is initially loaded
snap2 - after the wysihtml5 is created
snap3 - after the wysihtml5 is removed
Are there memory leak? If there are, how do I prevent it from happening? (My backbone application can possibly create/destroy 100+ wysihtml5, so a clean removal of wysihtml5 is quite important!)
First of all it is not clear is the test works properly or not because nothing happens with the page when I click create button. It would be much more useful to have a repeatable test.
Nevertheless I did the test and found that the test page (working or not) have no leaks.
On the each click it allocates small amount of memory and releases it on the next click.
Sounds like the page creates the detached dom tree on the first creation and keeps it alive.
It makes sense to do warm-up create and delete actions before the first snapshot and filter everything except the objects that were allocated between first and second snapshot.
This technique was described here.
I have a ListView object which calls the forceLayout() method to re-render itself after its css property display is set to none. The reason i'm calling the above method is because I have a master-detail list of many listviews with only one listview visible at a time. After each list item in the master-detail list is selected the corresponding listview will be displayed.
Everytime the forceLayout() method is called, the memory increases by around 10mb and is not reclaimed even after the app is suspended. Is it a bug or am I not supposed to be calling the method frequently?
Btw, I'm running Visual Studio RC 2012 on Release Preview.
Thanks in advance.
A ton of memory leaks were fixed between Release Preview and RTM, so my first suggestion would be to grab the RTM bits and try that.
Failing that, it's probably an issue with your code holding on to references to your data or the rendered DOM elements, but without seeing your code it's hard to say what it might be.
I am developing an app in Java ME using Netbeans IDE, where I'm creating 3 Forms which contains Button, Command (OK and back) and Image in the 1st Form.
Using OK Command I can transfer the control to the 2nd form. This works
In 2nd Form I have 2 Command OK and Back. On click of OK it should go to the 3rd Form. On click of back it should return to the 1st Form.
When I am in the 2nd Form, I'm neither able to transfer to the 3rd nor to the 1st Form.
I am getting the following exception.............
java.lang.OutOfMemoryError
(stack trace incomplete)
An exception occurred during transition paint this might be valid in case of a resize in the middle of a transition
Please help me out.
Thanks in advance
Sanjay's answer is correct however if it doesn't solve the problem I would guess you have a recursion somewhere in your code leading to a stack overflow. Many J2ME VM's fail in triggering the stack overflow exception and instead throw an out of memory error.
Just use a debugger and walk over the code to see the recursion.
With the informations you provided, The possible issue is with the image in the first form, you need to keep track of the size of the image you are using. When an image is loaded, the data is decompressed to a pixel array. Pixels can need anything from 2 to 4 bytes each, depending on the device.Say an 800x600 image has 480,000 pixels, so will need at least 1Mb of heap (possible as much as 2Mb) to load it. This will explain why you are running out of memory. During a transition it may be LWUIT makes a local copy of the Image to "transform" (redraw) it(though I'm not sure) so its not a surprise if you need more memory while transition.
Here is a good read which might help you : Memory Leaks In LWUIT And Tracking Memory In Java ME
You can extend the memory of the emulator. You have to click on Properties of the project / Platform / Manage emulators / Tools & extensions / Open preferences / Storage
In this window you will see heap size, write here 1000 f.e. and try it again.
When you swiching to 2nd or 3rd pass object of that class & display object(which is from mdilet) with next form constructor, and when you calling back button just write one line of code like display.setCurrent(previous_form_object); & you know how to go next form when you clicking ok command. And one thing which is mentioned by Sanjay.
Thanks
Preamble:
The view controller's view I'm talking about is used in a UISplitViewController as the details view. It gets replaced if the user navigates using the UINavigationController of the split view. When hitting "Back", a new instance of my problematic view controller is created and gets assigned to the split view controllers array of controllers.
Everytime my view shows up, I see an 8MB block being allocated in Instruments. Navigating forth and back for a while will eventually crash the app.
In detail:
In my class overriding UIViewController I have a:
private UIColor oBgColor = null;
in ViewDidLoad():
this.oBgColor = UIColor.FromPatternImage ( UIImage.FromFile ( "Data/Images/background.jpg" ) );
// This line here causes memory to go up by 8MB!
this.View.BackgroundColor = this.oBgColor;
in ViewDidDisappear():
// These lines should sucessfully get rid of the allocated 8MB chunk.
this.View.BackgroundColor = UIColor.Clear;
this.oBgColor.Dispose();
this.View.Dispose();
Code reaches ViewDidDisappear() as expected, view is gone.
The 8MB block is allocated ONLY if I assign this.oBgColor to the view's BackgroundColor. Leave that line out and all works (but I don't have a background).
Each time the view gets shown, I see another 8MB getting wasted.
What's going on here? Is BackgroundImage known to be leaking?
Interesting sidenote: if I add a UIImageView as a subview and use its image instead of assign to the view BackgroundColor property, memory hardly goes up at all and gets properly released.
I wrote a sample based on your code, and while memory usage does go up when it is assigned, there is no leak (I toggled the image on and off 100 times, and memory didn't change).
The reason it goes up is the BackgroundImage property is backed by a copy #property in Objective-C, which means that the entire object is copied on assignment, so if you have a huge pattern image, and then assign it, you will for a brief period have 2 copies of the image in memory.
The reason you see the memory increase is as I explained to you on IRC, MonoTouch does not have a compacting GC in v3.