My app uses a lot of javascript with backbone.js that manipulate DOM triggered by various events. It sometimes causes tab crash on Google Chrome(just tab crash and not the whole chrome crash). We have been investigating what is actually causing this issue, but there is no clue. We monitored memory by tab from chrome task manager, but crash happens even when memory use is small.
Is there any way to debug this kind of issue? We have no clue in identifying what the problem is.
UPDATE
The problem is that it is not easy to replicate the crash intentionally. It sometimes happen to some users. And those users normally repeatedly experience that (typically after clicking submit button). On the other hand, for other users, Chrome still works fine even though the tab starts to use over 200M memory after complicated DOM manipulation. Using profiling tool on developers tool might be one way, however it looks really a lot of work till identifying the issue. Would be great if somebody knows efficient way to identify what the problem is...
What we also know is that we have been suffering from memory leak. So, we started to unbind events once DOM the events are bound to got deleted. That helped us avoid huge memory usage as long as we monitor from task manager. However, we do not know we have done this well enough and it has something to do with the tab crash...
Open up the developer tools and click on the Console tab and add some console.log(message); throughout your code to see where it makes it before it crashes. Without more information there isn't much else to do.
Related
I suspect my one-page javascript app contains a memory leak somewhere. Weak devices running Firefox or Chrome seem to crash eventually if the page is left open. I'm trying to determine whether reloading the page would be expected to free the memory or not.
I understand that memory handling is specific to the browser, so the answer may differ in Chrome or Firefox.
NOTE: I recognize that browsers are mentioned a lot in this question (which would be off topic), but the point of this question is about javascript debugging, which I think is very on topic.
Barring browser/extension bug, browsers free up resources when they are no longer needed; Firefox clears compartments, Chrome kills processes and associated storage.
Firefox does its best but may take some time to clear the memory and may create zombie compartments on occasion:
Compartments are destroyed when they are garbage collected. This happens some time after the last reference to them disappears. This means there can be a delay between a page being closed and its compartments disappearing...
Sometimes, due to bugs in Firefox, the Add-on SDK and/or add-ons, compartments are created that are never destroyed. These are a particular kind of memory leak, and they cause Firefox's memory usage to increase gradually over time, slowing it down and making it more likely to crash.
Chrome uses a process per tab (and really subprocesses for some entities within a tab as well IIRC e.g. plugins, iframes, etc.) to the same effect. Though a quick check against chrome://memory-redirect/ and refreshing a tab looks like the same pid is used. So a refresh is not a completely clean slate.
FWIW Chrome has a "Force Reload" that clears the cache and might be either useful for clearing more memory or a placebo: cmd-shift-r
I'm not really familiar with the internals but I've only seen things not reliably freed up between refreshes when a particular browser is getting too clever and trying to preserve things when you're not changing origins etc. in an effort to boost load performance.
In short, you could be tripping up a browser bug if you're not seeing memory freed as you expect but you'd want to use the various "about:memory" tools to verify that and at that point it would be on you to avoid such behavior and/or report the issue to the browser's dev team.
Otherwise, I think you're best served by addressing your own memory leaks within the page using the various tools available.
A good way to debug the resource usage of JS is to use the Firefox performance monitor within the inspection tool. Firefox Dev Edition has more in-depth tools
Press F12 when on the page and click on the little speedometer icon in the inspect window; this will open the performance monitor. Press the "Start Recording" button and Firefox will begin to benchmark all script timings, CSS activity, user input etc. on the page.
When you feel that it has been running for long enough, stop recording and you will be presented with all the data. At the top will be a chart displaying performance and you can click on any part and examine all the scripts running at that time.
A full tutorial for the performance tools can be found here
I have an ASP.NET MVC application that makes pretty heavy use of javascript and JQuery for both administrative functions as well as customer-facing functions. Recently I reorganized the administrative screens to be able to more cleanly fit administrative controls for some new features.
I tested using IE and Chrome and found that there was a slight, but acceptable hang in one of the busier pages. However, the main person who uses the admin pages uses Firefox and kept reporting an unacceptable hang. I finally checked it out and found that what hangs in Chrome and IE for 2-3 seconds hangs in Firefox for 10-12 seconds, which is no good.
Not knowing where to turn, I wound up installing Glimpse and got it configured and running just fine, but I'm still having trouble figuring out how to drill into it to find out what area of the page is causing trouble. All I can tell so far is that it is definitely something with how the client (Firefox) is rendering. To be clear, it happens on all browsers, but for some reason it is way more pronounced in Firefox.
Can someone please give me some pointers on how to get started on diagnosing the issue? I'm not married to the idea of using Glimpse, but it seems like a pretty decent tool from what I can tell.
Thanks for your help.
Based on what you're describing, the problem appears to be client side. With that said, Glimpse may not be as well-suited as using Firefox's own profiler.
SHIFT+F5 will bring up the web developer performance screen. From there, you can begin/end a performance analysis and gain more insight into what may be taking longer than expected.
It may also be worthwhile to look at the network tab and make sure assets are loading in a timely manner.
Keep in mind as well that add-ins could play into the latency. If the end-user has a setup that performs post-page processing (such as Greasemonkey scripts or (recalling an earlier add-in) a Skype plugin that used to transform phone numbers on the page to direct-dial links), that would also play a part in the performance. A good way to rule these out is to hold down SHIFT while starting up Firefox (effectively running it in Safe Mode), which would determine if it's Firefox itself or an add-in that's to blame.
So tried my hand at profiling some code and I figured the easiest way to do it (at least on Firefox) was to use either console's time/timeEnd or profile/profileEnd, and I tried both.
The problem I have is with the number of runs I can do before Firefox crashes on me. Now I won't paste the code here because it's typical benchmarking code (and it's very messy), but obviously the gist of it is that it runs functions (a test is represented with a function), logging their execution time for a certain number of runs.
Now with for example, 5e4 it sorta works but I don't think it's enough to spot (very) micro optimizations, but more than that, it crashes.
So how do you profile your JavaScript? Because this way, it's barely feasible.
When I used to profile my JavaScript code I used Chrome's profiler; the JavaScript Console in the developer view gives it, and it pretty much worked for me. Have you ever tried it?
I have tried profiling a page with a lot of scripting in Firebug on FF4 and the same in Chrome (last version). Firefox crashed within a second or two, Chrome didn't seem to have problems with it. Maybe you can find something on it in the Firebug issues list?
Although not a traditional code profiler, I recommend Google's Speed Tracer:
Using Speed Tracer you are able to get a better picture of where time is being spent in your application. This includes problems caused by JavaScript parsing and execution, layout, CSS style recalculation and selector matching, DOM event handling, network resource loading, timer fires, XMLHttpRequest callbacks, painting, and more.
I think the profiler in the JavaScript Debugger (aka Venkman) is quite good. The version currently on addons.mozilla.org is not compatible with Firefox 4, but the change necessary to make it work has been committed. See https://bugzilla.mozilla.org/show_bug.cgi?id=614557 for details.
dynaTrace AJAX edition(free)- one more tool in your bag. Offers a little bit more detailed performance metrics, IMHO. They used to have it only for IE, but their new one supports FF too. Also see Steve Sounder's blog
I've written a lot of code for a website I'm developing and only just now realised it has a memory leak. I noticed Firefox getting rather slow over the day and checked my task manager to find it idling at 600,000 K.
Seemed odd and so I killed it/restarted it. Then realised that, while watching the task manager, the more I played around with my website the higher the memory usage got in Firefox.
Now, I have a lot of code... I don't want to have to recode it and try do it better this time around. So how can I look over my code and identify memory leaks? It's pretty much all jQuery stuff (binding clicks, changes, etc...) and AJAX (using jQuery UI tabs).
How can I fix this? >.<
You need to use a JavaScript profiler, like this addon for Firefox. It will help you find the memory leak(s) and you will have to fix it.
Recently I have been having issues with Firefox 3 on Ubuntu Hardy Heron.
I will click on a link and it will hang for a while. I don't know if its a bug in Firefox 3 or a page running too much client side JavaScript, but I would like to try and debug it a bit.
So, my question is "is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?"
I would like to be able to see what tabs are using what percent of my processor via the JavaScript on that page (or anything in the page that is causing CPU/memory usage).
Does anybody know of a plugin that does this, or something similar? Has anyone else done this kind of inspection another way?
I know about FireBug, but I can't imagine how I would use it to finger which tab is using a lot of resources.
Any suggestions or insights?
It's probably the awesome firefox3 fsync "bug", which is a giant pile of fail.
In summary
Firefox3 saves its bookmarks and history in an SQLite database
Every time you load a page it writes to this database several times
SQLite cares deeply that you don't lose your bookmarks, so each time it writes, instructs the kernel to flush it's database file to disk and ensure that it's fully written
Many variants of linux, when told to flush like that, flush EVERY FILE. This may take up to a minute or more if you have background tasks doing any kind of disk intensive stuff.
The kernel makes firefox wait while this flush happens, which locks up the UI.
So, my question is, is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?
Because of the way Firefox is built this is not possible at the moment. But the new Internet Explorer 8 Beta 2 and the just announced Google Chrome browser are heading in that direction, so I suppose Firefox will be heading there too.
Here is a post ( Google Chrome Process Manager ),by John Resig from Mozilla and jQuery fame on the subject.
There's a thorough discussion of this that explains all of the fsync related problems that affected pre-3.0 versions of FF. In general, I have not seen the behaviour since then either, and really it shouldn't be a problem at all if your system isn't also doing IO intensive tasks. Firebug/Venkman make for nice debuggers, but they would be painful for figuring out these kinds of problems for someone else's code, IMO.
I also wish that there was an easy way to look at CPU utilization in Firefox by tab, though, as I often find myself with FF eating 100% CPU, but no clue which part is causing the problem.
XUL Profiler is an awesome extension that can point out extensions and client side JS gone bananas CPU-wise. It does not work on a per-tab basis, but per-script (or so). You can normally relate those .js scripts to your tabs or extensions by hand.
It is also worth mentioning that Google Chrome has built-in a really good task manager that gives memory and CPU usage per tab, extension and plugin.
[XUL Profiler] is a Javascript profiler. It
shows elapsed time in each method as a
graph, as well as browser canvas zones
redraws to help track down consuming
CPU chunks of code.
Traces all JS calls and paint events
in XUL and pages context. Builds an
animation showing dynamically the
canvas zones being redrawn.
As of FF 3.6.10 it is not up to date in that it is not marked as compatible anymore. But it still works and you can override the incompatibility with the equally awesome MR Tech Toolkit extension.
There's no "process explorer" kind of tool for Firefox; but there's https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Venkman with profiling mode, which you could use to see the time spent by chrome (meaning non-content, that is not web-page) scripts.
From what I've read about it, DTrace might also be useful for this sort of thing, but it requires creating a custom build and possibly adding additional probes to the source. I haven't played with it myself yet.