Memory leak on calling forceLayout - winjs

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.

Related

Will "addValueChangeListener" cause memory leak?

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);

ReleaseDesignerOutlets deallocated outlets not being reallocated

I have the following scenario:
UIViewControllerA pushes UIViewControllerB on to the navigation stack via a storyboard segue;
UIViewControllerB is now currently onscreen and I simulate a memory warning via the iOS Simulator.
UIViewControllerA.DidReceiveMemoryWarning() gets invoked as well as UIViewControllerA.ViewDidUnload().
In method UIViewControllerA.ViewDidUnload() I call ReleaseDesignerOutlets() as recommended. UIViewControllerA designer outlets are now deallocated and null.
I hit the "back" button on the navigation bar which dismisses UIViewControllerB and causes UIViewControllerA.ViewDidLoad() to be invoked.
At this point I would expect the designer outlets to be initialised but they are still null and my application crashes due to null pointer exception.
Have I fundamentally missed something? I am using the Monotouch 5.4.0.
EDIT
I found this post which describes the solution to problem to be the same as what I discovered, that is, don't release the designer outlets in ViewDidUnload().
Update: It's finally crash free! (or at least it seems to be)
For future reference, it looks like the big lock-up was due to my disposing of my UIWebView outlet in the ViewDidUnload event. The UIWebView is defined in the xib, and not added as a subview in code.
When memory was running low, the view unloaded and removed the UIWebView outlet. Subsequently, the ViewDidLoad event would fire again, as the app recovered (!?), but it would lock-up. I expected the UIWebView to be reinstated in when the view reloaded (i.e. the xib reloaded).
Is this not the case? I thought it was good practise to dispose of outlets in the ViewDidUnload event?
As soon as I commented out the "webView.Dispose(); webView = null;" line of code, it's been working as expected.
What a day!
EDIT
Further debugging reveals that SOME designer outlets are getting reallocated such as UIImageView and UIScrollView, others such as UITextField and UIBarButtonItem are not.

LWUIT- out of memory exception in JavaME

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

Memory leak JQuery - all browsers

I am using jquery in my web page. I see a lot of memory leak happening and after a while the whole browser grinds to a halt. I used the sieve tool and noticed that there is a contsant increase in the no. of DOM elements, everytime by a no. of 4.
Am I doing something wrong in the way I have associated events?
Or is it because I am using setTimeout to redraw my app every X seconds?
Event association:
$('.bir_Names').click(showNames);
The selector $('.bir_Names') evelautes to a set of some 300 elements each of which call the function on click.
setTimeout
Every X mins I remove every single HTML element in the app and rebind fresh data and associate the events. I use jquery remove() to delete elements. have tried innerHTML = '' and empty() also.
I see a jump of nearly 30-40 MB for every redraw and Sieve indicates that none of the deleted nodes are actually removed.
Anyhelp would be greatly appreciated. This thing is driving me nuts.
Thanks.
You don't mention which browser, but some googling seems to indicate that this is a known problem with IE. Here's one potential workaround:
http://forum.jquery.com/topic/possible-memory-leak-in-remove-and-empty
Note that that's referring to a 1.2.x release of jQuery. Before you do anything, make sure you are running the latest 1.6.x release to first see if the defect has already been fixed within jQuery.
[EDIT] ack...you DO state your browsers...'all'...so maybe disregard that first link.

debugging memory leaks in Monotouch app

I have a magazine Ipad app that dynamically adds/removes webviews from a scrollview to keep the memory usage low. For example, I have 3 view containers, and in each one I can remove existing children...
foreach (UIView subv in targetView.Subviews) {
foreach (UIView subsubv in subv.Subviews) {
subsubv.RemoveFromSuperview();
subsubv.Dispose();
}
subv.RemoveFromSuperview();
subv.Dispose();
}
and then add a new Web subview component (or scrollview with webviews) to the container.
I added the second level of children deletion, but there is probably another level in some cases. The emulator is perfect, but on the IPad, the memory usage just increases until it crashes with a low memory exception.
so.....
i) Does monotouch destroy a UIView with all nested children automatically?
ii) Instruments is not showing any memory leaks, what is the best way to debug this?
thanks.
If there are no more references to your UIView then it should get GC'd. A quick way to find out if your object was collected is to create a class that inherits from UIView (or whatever class you're using) then create a finalizer/destructor for the class. In the finalizer do a console write.
~MyView()
{
Console.WriteLine("MyView: finalized");
}
When you run your program make sure you see this being written to the console when you expect the object to be collected. In my experience, the simulator collects the objects almost as instantly as the object looses it's last reference. On the device it may not be as quick.

Resources