My Sencha Touch app (demo is here: http://www.bodbot.com/MobileApp/senchademo/index.html) has been crashing on a relatively regular basis on Android and Windows Phone. I have yet to figure out the root cause of the crash despite a fair amount of investigation, so any help would be awesome. Here's what I have so far:
On Android, when the app crashes, I get a signal 11 sigsegv error. Due to the fact that I am working pretty much exclusively in javascript, my assumption is that the likely cause of this segmentation fault would be some sort of a memory leak, since I'm not writing any code that's pointing at anything in memory.
When I use Chrome's timeline memory analysis and use the app very heavily, the memory usage pattern does seem to clearly indicate a memory leak, especially when compared to similar usage on one of Sencha Touch's demo apps. (screenshots below)
My problem is that I can't track down the (assumed) memory leak. I'm doing everything that I've found about optimizing sencha for memory:
I'm using listener delegates pretty much exclusively
I make sure that most components that aren't currently being viewed are destroyed
I don't go too nuts on the global variables within javascript
It does look like Chrome's "Record Heap Allocations" might be able to reveal something, but given the sheer volume of pieces that it's tracking, I'm having real trouble making any sense of it.
Am I missing a method for optimizing memory in Sencha Touch? Is there a more effective way than Chrome's Record Heap Allocations for tracking down Sencha Touch app memory leaks?
Screenshots:
I have struggled around with the heap profiler in chrome but it is very confusing. Especially if there are minimized libraries inside. But even the DOMElements views, elements which may not be removed are very unclear presented.
Are there any tips how to use the heap dump in chrome to find JS code that leads to memory leaks, code that cannot be cleaned by GC... and how to find elements messing around even if removed from dom?
In other words, how to read heap dump in chrome correctly? Dominators View? Comparison?
Chrome now offers much better tools to find memory leaks, than at the time of most answers.
Here is to find memory leaks in javascript with a recent Chrome browser:
Press F12 to open the developer tools and go to the Memory Tab.
Pick a feature or a part of your app that you want to inspect for leaks. For example, when a dialog is opened and closed again, the memory used by it should be released.
Do the action (for example opening a dialog) you want to check for memory leaks once, so potential global services can be loaded. This prevents these objects, that are intentionally preserved from showing up as leaks.
Now select Record Allocation Timeline and press Start. Repeat the action you want to check for leaks a few times. So for example open a dialog, close it and repeat. While you do this Chrome draws the timeline with partially grey or blue bars. Usually you see a bar for each time you performed the action on your page. When the bar from several previous iterations of the action stays partially blue it usually means there is a memory leak. The blue part of the bar represents memory that was allocated at this time and has not yet been released again. Stop the recording by pressing the red dot on the top left of the developer tools.
When you see potential leaks you have to inspect this part of the timeline to find the source. Select a part of the timeline that is a few iterations of your actions in the past. And Chrome will show a list of object-types that are still present in the memory. The retained size column gives you an impression how much memory is still used. Browse into one of the object-types and select an object. If you do that, the list of retainers will appear below.
The list of retainers shows the "parent" objects that reference the selected object. Now you need to look at the retainers and your code to understand why the memory has not been released. For example in the image you see the object of the type scope. The second line says the scope is "context in initFormat()". The problem was that initFormat was an event listener that was not unbound after a dialog was left.
After you fixed your code check if the problem has been solved. Refresh the page and repeat the steps 3 to 6 again. If you have never checked for memory leaks before it is not unlikely that you find multiple problems.
Additional hints:
Sometimes there are caches that retain a part of the memory. Usually you can ignore them.
When you see the HTMLDivElement or other DOM elements in the list of object-types have a look. If the objects in this list are highlighted red it means they are no longer present in your page. This means they must be reference somewhere in the code. You may have forgotten to unbind an event listener.
Read about memory leaks in general, so you can identify them quicker in your code.
In Chrome developer tools, there is a Timeline - Memory tab:
We can watch the memory occupied by it.
There is also Profiles - Memory, where we can take a snapshot and see what’s inside. Snapshots can be compared to each other:
Most of time, it doesn’t tell you anything. But at least you can see which objects are piling up, and probably the structure of the leak.
Other way is using 'Task Manager'
here is an article regarding this:
http://www.javascriptkit.com/javatutors/closuresleak/
Google open sourced a tool for this purpose, leak-finder-for-javascript. They also proposed a method so-called the three snapshot technique (also see a brief description in this article).
First paragraph of the leak-finder link
Note: jsleakcheck is no longer supported! It was working against an unofficial and unstable Dev Tools protocol for taking heap snapshots.
The protocol is being worked on, and it is not stable enough so that I
could keep jsleakcheck working with various Chrome versions. In
addition, a lower level compatibility tool,
remote_inspector_client.py, which jsleakcheck was using to communicate
with Dev Tools, got removed.
I found this article very insightful:
http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-profiling-in-devtools/
It does cover the chrome developer tools extensively and explains very well how to go about when your application seems to have memory issues.
Quoted from JavaScript Kit:
If you are developing client-side re-usable scripting objects, sooner or later you will find yourself spotting out memory leaks. Chances are that your browser will suck memory like a sponge and you will hardly be able to find a reason why your lovely DHTML navigation's responsiveness decreases severely after visiting a couple of pages within your site.
A Microsoft developer Justin Rogers has described IE leak patterns in his excellent article (from web.archive.org).
In this article, we will review those patterns from a slightly different perspective and support it with diagrams and memory utilization graphs. We will also introduce several subtler leak scenarios. Before we begin, I strongly recommend you to read that article if you have not already read.
Why does the memory leak?
The problem of memory leakage is not just limited to Internet Explorer. Almost any browser (including but not limited to Mozilla, Netscape and Opera) will leak memory if you provide adequate conditions (and it is not that hard to do so, as we will see shortly). But (in my humble opinion, ymmv etc.) Internet Explorer is the king of leakers.
Don't get me wrong. I do not belong to the crowd yelling "Hey IE has memory leaks, checkout this new tool [link-to-tool] and see for yourself". Let us discuss how crappy Internet Explorer is and cover up all the flaws in other browsers".
Each browser has its own strengths and weaknesses. For instance, Mozilla consumes too much of memory at initial boot, it is not good in string and array operations; Opera may crash if you write a ridiculously complex DHTML script which confuses its rendering engine.
Although we will be focusing on the memory leaking situations in Internet Explorer, this discussion is equally applicable to other browsers.
continue reading...
Here is a very good post about how to find memory leaks using the Google Developper Tools: http://gent.ilcore.com/2011/08/finding-memory-leaks.html
Here is another good web page about that : http://javascript.crockford.com/memory/leak.html
I don't see mentioned window.performance.memory, which gives you the run-time ability to monitor and take action based on memory usage.
window.performance.memory:
MemoryInfo {
totalJSHeapSize: 7084834,
usedJSHeapSize: 6486770,
jsHeapSizeLimit: 4294705152
}
For a handy percentage, use this:
window.performance.memory.usedJSHeapSize / window.performance.memory.jsHeapSizeLimit
https://developer.mozilla.org/en-US/docs/Web/API/Performance/memory
Are there any add-ons for Firefox that I can use to find out with part of the JavaScript causes memory leaks?
I've got nothing for firefox, but the webkit inspector in Chrome has a profiler built in that is great for that kind of thing.
As an added bonus it also shows you all browser events such as repaints, so you can engineer your code to have the least impact on the browser.
Use Drip.exe / IEleak, I used it a lot to search for memory leaks!
Other hits:
jQuery itself prevents a lot of memory leaks!
Test your code with http://jslint.com
There is a tool by Microsoft itself, but I don't know it is up to date: http://blogs.msdn.com/b/askie/archive/2008/12/31/javascript-memory-leak-detector-for-internet-explorer.aspx
There is also integration with Visual Studio: http://berniesumption.com/software/how-to-debug-javascript-in-internet-explorer/
There is a good article about mem leaks http://www.ibm.com/developerworks/web/library/wa-memleak/
http://www.debugbar.com/?langage=en
The best memory profiler I've found is for IE (supports even IE6 ;-). Give it a go - you will be surprised how good it is:
http://ajax.dynatrace.com/ajax/en/
Is there any way to find memory leaks in javascript or jquery.
i am working on javascript alot these days. I moved from middletier to UI.so I want to know if there is anyway to find them.
thanks in advance.
Memory Leak Patterns in Javascript
http://www.ibm.com/developerworks/web/library/wa-memleak/
Plugging memory leaks in JavaScript is easy enough when you know what
causes them. In this article authors Kiran Sundar and Abhijeet
Bhattacharya walk you through the basics of circular references in
JavaScript and explain why they can cause problems in certain
browsers, especially when combined with closures. After seeing some of
the common memory leak patterns you should watch out for, you'll learn
a variety of easy ways to work around them.
Google Chrome has the ability to take heap snapshots and compare them, which can be used to detect memory leaks and analyse memory consumption in general. There is an article about heap profiling at Google Developers that explains everything.
Debug.js does global leak detection and type checking.
Please tell me how to find out the memory leak in browser and what is the best way to solve the problem. Is there any guideline for writing javascript to avoid memory leak?
And also if you can tell me some problem which you experienced related to memory leak and how did you debug and find out the solution would provide a great understanding to me.
Thanks
Look at this IBM article on Memory leak patterns in JavaScript
For Internet Explorer you can try sIEve or the JavaScript Memory Leak Detector from Microsoft (The link to the documentation seems to be broken). In Firefox there is the Leak Monitor Add-on. There is also a list of tools for Firefox here.
UPDATE:
There is a new version of the Microsoft memory leak detector at the link below.
Link