Develop Reference

website crashes in IE, possibly a memory leak?

A website I'm working on crashes in IE8 through 10. I have been trying to determine if it is related to a memory leak, but the tools available for IE are not really great. I've tried using Sieve ... as well as dynaTrace ... Sieve reports no memory leak, but does report on multiple orphaned dom nodes. dynaTrace does not support memory analysis in IE, and the issue does not seem to present itself in Firefox.
I've reviewed heap snapshots in Chrome Dev Tools... and garbage collection seems to be fine there after about 10 seconds or so of the site loading.
Here is the site in question: http://midlandsbiz.whosonthemove.com/
After several minutes on the site in IE, my AVG will pop-up saying that it is consuming too much memory. This is also evidenced by my fan whirring on my laptop, and the ultimate crash of the site.
This happens on multiple computers, on different networks, using different versions of IE.
I was also able to replicate the issue using the WP theme author's site:
http://kopatheme.com/demo/passion/
I'm getting no response / support at all from the WP theme author about this issue.
I was hoping that someone had some ideas on what might be causing this... or could point me in a direction for some tools that I can use to profile javascript memory usage in IE?

You have some major memory leaks and a HUGE memory footprint. There are actually great memory profiling tools in IE, just open F12 and choose the memory profiling tool. You will want to start a profile. When you take a snapshot you will get a simple visual telling you the size of the page in memory and how many objects. When you have a memory leak you will see a blue circle with the number of leaks. Clicking on that will take you to a view of the objects and you can swim through the tree to find the source of your issues.
I can also tell you have many fundamental performance issues in the site. You have over 200 HTTP requests and 4MB of content. You also have many 404s.

Debugging heavy single page application

We're developing quite heavy single page application (SPA). However, it recently started to crash from time to time and it appears almost impossible to debug it. The traditional tools such us firebug or chrome's tools were also not very useful (perhaps they were not used correctly?).
Is there any tool that would allow me to view a crash log of a tab where I could find what caused a memory leak (or whatever the reason for the crash was)?
Thanks

You can try to use Chromium which is kind of browser especially for developers.
It has a batch of plugins for debugging and testing websites and SPA.
For example for memory leaking you can try to use LeakSanitizer.

Forcing garbage collection in Google Chrome

We are developing a single-page web app with ZK which constantly communicates with server and updates parts of its screens. Updating can be as frequent as 1s. During these updates, references to large ammounts of JS objects are lost and those objects have to be cleaned by garbage collector eventually.
As far as we've figured out, Chrome only runs its garbage collector on inactive tabs. This is a problem for us, because the app's tab is usually active and almost never refreshed, thus JS objects never get collected. If left active for enough time, the tab eventually crashes (Aww Snap message).
We need to initiate garbage collection manually. So far we've tried running Chrome with --js-flags="--expose-gc" and running gc(), but it throws an exception:
ReferenceError: gc is not defined
This doesn't happen on Firefox -- memory usage is more or less a constant.
Force refreshing the page is not an option.
We would be grateful for any and all suggestions.
EDIT: we've tried running window.gc() and gc() both on Chrome versions 23.0.1271.97 m and 25.0.1364.2 dev-m

You can fetch code of Chrome Dev Tools, modify it so that ProfilerAgent.collectGarbage(); is called every now and then (it's a code that is called when you click 'Collect Garbage' button on the Timeline panel) and run Chrome with your version of DevTools using --debug-devtools-frontend flag.
However, this solution is quite extreme, try it only when you get really desperate. Till then, I propose profiling your application and checking out why v8 decides not to clean the garbage (or can't clean the garbage). Timeline panel of DevTools will help you out with this. Start with checking if 'Collect Garbage' button at the bottom of this panel really does its job, if not - you probably have a memory leak (at least, according to v8). If so, try leak-finder-for-javascript.
[EDIT] I removed info about chrome extension, as it turns out that gc() can be called from webpage code when --js-flags="--expose-gc" is used. At least on my 23.0.1271.64.

In Chrome Developer Tools you have "Timeline" section, from around Chrome 53. you have there button looks like Garbage Can. clicking on it and it forcing the garbage collector to run.
Update:
The GC button moved to Performance Tab in more recent versions of Chrome.

I found a solution. Apparently Chrome leaks DOM nodes, at least in the current version (26.0.1410.65 right now)
I recorded dev tools timeline in my app and it showed the Event Listeners count going up and down rhythmically along with my app screen's contents, but the DOM Node count was steadily increasing over time, until the tab crashed.
I tried the latest Chrome Canary (28.0.1500.3) and they seem to have fixed the problem. DOM Node count graph now follows the same rhythmic pattern as the Event Listeners.
The thing that gets me is...why doesn't gmail ever crash? I usually keep a tab open for weeks at a time...

Profiling a Chrome application

We are creating a Chrome application that we hope to release in the coming weeks. We have already distributed to a bunch of alpha testers, and, even though feedback is generally good, we have had complains by a bunch of users that our extensions is expensive in terms of RAM.
We also had reports of a too high CPU consumption.
Now, we have improved what seemed obvious, but we are almost 'blind' in terms of execution.
What would be the good strategy to profile both memory and JS calls for our Chrome application?
Please note that this application is a full native application, so maybe we can apply some generic javascript profiling tips?

As people have mentioned, you can use the Chrome Developer Tools to profile memory usage.
For CPU and RAM, it's not particularily scientific, but you could get a broad gauge by having no applications open other than Chrome which has about:blank open and your OS' Activity Monitor or Task Manager.
Look at the CPU and RAM readings for Chrome on about:blank, which is about as idle as it will get - then compare that to the readings when your Application is running.
Disable all extensions too, to take them out of the equation.
Hope this helps.

Chrome Dev Tools very slow to respond in large web app

I have a large, javascript heavy web app that I am working on. I am experiencing very slow response times from Chrome Dev Tools for XHR responses and console loggging (3-5 secs). The actual app is running fast and responsive, only dev tools looks like it is suffering.
Does anyone have any idea why Chrome Dev Tools is becoming sluggish as my app grows?

Devtools are like any other debugger; they hook into the normal processing flow of an application, and store quite a bit more information than is normally required. This is much more work than simply rendering the page without debugging enabled, so it will indeed be slower.
That said, 3 seconds to respond to console.log seems high. I'd suggest that you first test the application in a nightly version of WebKit. If it's responsive in WebKit, but not in Chrome, please file a bug against the inspector via http://new.crbug.com/ along with any information you can provide about what scenario causes the slowness.
If it's equally sluggish in WebKit, please file a bug against WebKit's Inspector component: https://bugs.webkit.org/enter_bug.cgi
Either way, post the bug ID here, and I'll see that it's triaged into the correct team.

I "fixed" the slow chrome developer tool by (under SOURCES tab)
clearing the "watch" list that accumulated over time...
clearing all the "snippets", i had dozens as well...
Not sure which of both made the most difference, but it certainly made a difference

This is an old question, but it may help someone landing here later like I did.
Using Chrome 46.x/47.x on Linux (RHEL 7), none of the proposed solutions worked for me. What did work was to disable the setting "Use hardware acceleration when available", in the advanced browser settings.
I noticed in the process monitor/list that the Chrome renderer was taking up a lot of CPU, even putting a breakpoint or stepping throught statements in the debugger would take 10+ seconds!
Might be worth a shot.

Undock the developer tools into separate window.
In my case, it's work.

I struggled with this also, to the point where stepping through code using the chrome debugger was just so slow it took hours away from my productive development time. In watching the CPU utilization when debugging in chrome I would see it use up to as much at 40% of all 4 cores of my processor. I tried everything to no avail. Finally, I tried making the browser window of the page I was debugging as small as I could without losing any of the required view and miraculously it solved the problem. So, now I keep my debugger window popped out in a separate window, and make the window of the page I am debugging as small as I can and my debugging experience is very fast again. I have tested this over a period of weeks and it has held out. Hope this helps someone.