The "Dynamically updated data" demo on the HighStock website seems to leak memory in the current version of Google Chrome (24.0). I've tried it on Mac OS X 10.8.2 and Windows 7 (64-bit). I also tried Safari 6.0.2 on OS X, and both IE9 and Firefox 18 on Windows 7. The leaking only seems to happen in Chrome, and it always happens.
Given that this is a fairly prominent demo, I would have expected it to work well. But given enough time, it crashes in Chrome, giving the "Aw, Snap" error page. It can take a long time in the demo as written, but if you click the jsFiddle link and change the setInterval() call to 100 ms instead of 1000 ms, the leak is fairly obvious. A real application with multiple series and a decent amount of data can crash Chrome in just a few minutes.
Note that while data is being added continuously, the "shift" parameter in addPoints() is always true, meaning that old data is being discarded just as quickly. So the memory usage should be fairly constant--and on browsers other than Chrome, it is.
I'm not sure how to tell if this is a Chrome bug or a HighCharts one. And I haven't found a useful workaround. A conclusive answer to either aspect would be much appreciated.
Inspired by Mark's comment, I decided to try different versions of various things. First I tried the bleeding-edge versions of jQuery and HighStock. Chrome 24 (stable) still leaked. Then I tried Chrome 23 since it worked for Mark on Fedora, but it still leaked on Mac OS.
Then I tried the Chrome Canary build, 26.0. It worked, with no leaks! It exhibited the classic garbage collection pattern of building up a few dozen megabytes excess memory usage, then falling back down to "normal", every few seconds. So that's good news. The bad news is that Chrome Beta, 25.0, still leaks. So if other users of HighCharts experience this issue in the next couple months, they'll need to either use an "unstable" version of Chrome, or just a different brand of browser.
Related
we have a single page application built with javascript, angular, etc.
noticed that in Chrome (only) the memory usage is rising until the tab crash with the "Aw snap" message.
seems like Chrome is not running the garbage collector when it should.
after some research with old Chrome versions i've found that in version 61 everything works very good and the memory usage is very minimal, but in v62 and onward (including canary v66) the GC is not collecting, resulting in memory usage up to few giga. until it crash.
once i open the devtools the GC is collecting as it should and memory usage is normal again.
any idea what is happening?
Chrome developer here. It's hard to guess what might be going on. Please file a bug at crbug.com/new, include repro instructions, and post the bug number here.
My website (www.transferxl.com) relies on Javascript for compressing data. Compressing a 25MB large chunk takes about 1-2 seconds with most browsers (Chrome, Safari, Firefox, ...). IE11 takes over 40 seconds for exactly the same operation.
I thought IE11 was just painfully slow, so I decided to enable the profiler and see what is happening. To my surprise the same chunk was compressed in 2-4 seconds. Although still slower than Chrome, it was way faster then before.
Steps to reproduce:
Go to www.transferxl.com.
Open the developer console (F12).
Add a (compressible) file that is larger than 25MB.
Transfer the file and watch the console
You'll see a message how long it takes to compress the chunk of data.
Refresh the window (while still on www.transferxl.com).
Start the profiler.
Add a the same file again.
Transfer the file and watch the console
You'll see that the same block is now compressed much faster. You can also try it in reverse order. Results are stable. With the profiler on IE seems to compress 10-20 times faster then without the profiler.
Does anyone know what could be the problem? The profiler output doesn't show anything alarming. Has anyone else seen this issue?
I have tried doing exactly what you asked, and the uploads took less than 2 seconds on both Google Chrome (39.0.2171.65 m) and Internet Explorer (11.0.9600.17420). It appears as if Microsoft may have released this fix in one of their more recent updates. As far as I have seen, nothing of this sort was mentioned in the changelogs. Yes, I ran IE with the profiler disabled. I presume that the issue may have been caused by IE assigning process priority to scripts running with the profiler attached, since the profile also needs to function and render its output (supposedly) without affecting the functioning of the page itself. The compensation does not noticeably affect the computer's processor consumption in any way, but somehow just utilizes existing memory that has been allocated by IE prior to opening the profiler.
I spent a long time adding a lot of Javascript to our front-end. I did this all the while using FF (11.0). I just committed all the changes (which work fine on my local sandbox) to our dev server, and a QA tester noticed that an entire div is missing when viewing the page in IE 8.
This div does all sorts of fancy stuff with jQuery, allowing users to expand/collapse accordion panels, and drag-drop images from expanded accordions, etc.
It is 10 PM and I can't go to bed until I fix this break. I have tried using the IE Dev Toolbar that ships with IE (and is accessed via the F12 button), hoping it would catch some bad Javascript but nodda. Same for Firebug. The JS looks perfectly fine, it's just IE being stubborn.
What steps would SO take to start figuring out why IE won't display my jQuery-heavy div? It's really not as simple as backing out the changes one by one, because my code sprinkled and interwove functions and calls all over the JS page. Thanks in advance for any pointers or nudges in the right direction.
F12 Developer Tools
The F12 Developer Tools, when used properly, are generally speaking more than capable of finding odd problems throughout your code. You can audit your application to find long-running processes, add breakpoints and watch variables through the life-cycle of your page.
IE Compat Inspector(s)
Another great tool is the IE Compat Inspector, which will examine your code and look for any types of patterns or usage that might break your site in Internet Explorer. You can find this online at http://blogs.msdn.com/b/ie/archive/2011/04/27/ie9-compat-inspector.aspx for Internet Explorer 9, and http://blogs.msdn.com/b/ie/archive/2012/01/20/ie10-compat-inspector.aspx for Internet Explorer 10.
ECMAScript Compat Charts & Polyfills
Often times we mix up what features are supported by which browsers. It helps to keep a good compat chart handy, so you know if classList is supported in IE or not. If and when you discover that something isn't implemented in Internet Explorer, it's time to find a polyfill. Fortunately, there are many.
Web Debugging Proxies
These are just a few tools that you can use to trouble-shoot your site in Internet Explorer. Lastly is Fiddler 2 (a web-debugging proxy), which permits you to stand in between the client and server, tampering with data as it goes both ways. I typically use this to serve up custom files in the place of live server files when I'm debugging scripts. However, if you've got direct access to the server presently, this isn't all that necessary.
I've downloaded the latest version of IE9 beta and my site wrecks it. No problems on any other browser, but on IE9 it freezes on every page. The thing is, many other sites also make it gag.
Should I worry?
IE's fault or do my site and I need to do some serious soul searching?
How does one debug this stuff and are there a list of common culprits? Is it most likely a Javascript issue? jQuery?
If your site is dying on IE9 (assuming it's not the result of known IE9 bugs), you definitely need to address it. You can download tools like the IE Developer Toolbar to help you move about within your page once it's loaded, and there are other resources online like jslint that will help you examine some of your javascript and work on its quality.
If you find any specific issues that you're unsure of how to address, please don't hesitate to return here and post more questions - there are (literally) thousands upon thousands of brilliant minds waiting to assist you.
Update - You mentioned in the comments below that IE9 dies before you can even determine what is causing it to die. This is (unfortunately) the case with much software. Often times you can try to repeat the same actions in Chrome, Firefox, Opera or some other browser and see how it responds. Many times you'll find that another browser may provide an error without crashing entirely. This could give you some insight into what may be causing IE to crash.
Jonathan submitted a great answer about using jslint to verify the integrity of the JavaScript, and using other debug tools on other browsers to detect for a non-crash error. I did both and thoroughly went through my site, only to find that IE9 was still crashing!
So I looked into it and here's what I found: the main cause of IE9 beta crashes are add-ons that are incompatible with the new release. Adobe PDF viewers, printer add-ons, toolbars, etc. Most everyone has at least one add-on in their browsers. So I disabled all my add-ons and now my site works.
I'm not sure why my site seemed to crash more than others with IE9, but if people are having problems with there site, I'd suggest (1) disabling all add-ons just in case, and then (2) using Jonathan's answer (which I'll leave checked as the official answer since it has to do more with programming).
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.