Been googling around a bit for the last week or two and haven't come up with any leads.
I believe this started ever since the latest major chrome web browser update, from 68 to 69. (currently on version 69.0.3497.100 )
Basically, when I'm using the chrome dev tools and debugging some javascript, the browser crashes when I begin typing a variable name into the console. I'll get a character or two in and then bam, the whole thing crashes.
I'll close the browser, reopen it and still crashes immediately when typing in the console. Sometimes there are a few hours in between episodes, but this has been a persistent issue for too long and is severely impacting my ability as a developer.
Any help would be greatly appreciated. Thanks.
As pointed out on this Reddit post: Google Chrome 69 Issues, that particular version was riddled with bugs. One website, quoting here from the same reddit thread, titled their article as "Atrocious performance - Google Chrome 69".
While this is not a solution, the easiest thing you can do is update to the latest version. (70.0.3538.77, at the time of writing.)
Related
On some pages of my WebApp IE hangs with message Example page is not responding due to a long running script but I can't troubleshoot it since Developer Tools panel hangs as well and does not respond.
I have IE 11.
How do you troubleshoot this kind of issues?
Here's a blog post from the IE team's former program manager which describes exactly how to deal with your situation:
http://blogs.msdn.com/b/ieinternals/archive/2014/01/15/debugging-internet-explorer-with-windbg.aspx
They're not as simple as you would expect since you will need to use tools such as WinDbg but definitely adds some knowledge in your arsenal
For a while I've been trying to run a JavaScript CPU profile of some applications I've developed, but everytime I start running the JavaScript CPU profiler in Chrome Dev tools, the application will stop responding at all (same as the profiler).
However, I noticed that this is not specific to my application, since I've been able to reproduce the same problem in other popular applications like Travis-CI.
I've been suspecting of extensions and plugins, but running without them doesn't seem to make a different -- the problem persists.
I've tested simpler apps with the same technology (the To-Do MVC example built in EmberJS) and that profile works just as fine.
I'm currently using Chrome 40.0.2214.111 m (64-bit).
Any idea on what the problem may be?
Update: I've tested both under incognito and guest browser mode. I thought the guest browser made a difference because I was able to profile my application once without problems. However, trying that again proved that the problem still persists.
Furthermore, I've found that the freezing time does not seem to be related with the application itself. Sometimes it'll hang when I focus an element, sometimes when I move around, some other times when I am in the middle of writing into a textbox. There seems to be nothing specific about the functionality of the app that's triggering this.
I've also tried disabling most extensions, without luck. I'll try disabling plugins as well and run as bare of a Chrome as possible.
Update 2: I've disabled all plugins and extensions completely, but the problem persists. I've also let the session go on to see if it eventually recovers. After around 2 hours, it was in the same situation. No bigger CPU consumption nor memory consumption, and other Chrome instances or tabs worked perfectly fine. I was able to close the developer tools but not interact with the original page anymore.
Update 3: I've just upgraded to Chrome 41 because it has been released in the stable branch, and I know it does include a few more things in the profiling section. I tried again and it didn't seem to make any difference.
My problem may seem a bit vague (it is to me too), but here is my attempted explanation of it.
A few months ago, I implemented PDF.js in my web application. It was really useful, and I am using it for interactions with my clients.
Suddenly, last week, my clients reported to me "Aw, Snap" messages in Google Chrome on their PCs when they try to launch PDF.js. I have an iMac and two PCs at home, so I decided to test this out.
When I used Google Chrome on my iMac to launch PDF.js, I found it worked fine.
When I used Google Chrome on my first PC to launch PDF.js, I found it worked fine.
When I used Google Chrome on my second PC to launch PDF.js, even though it previously worked, it kept crashing and showing me "Aw, Snap" messages.
This was weird. I tried removing all the extensions, clearing the cache, clearing the LocalStorage, but nothing seemed to fix the problem.
I then realised, after some communication with my clients, launching PDF.js in Safari, Torch, Opera or Firefox on any operating system worked perfectly fine.
Why would this happen? I am using the web viewer in PDF.js. I also tried with the basic hello world example, but that broke as well (which I now find really weird), so I suspect there's something wrong with the rendering engine.
I also tried including the compatibility.js file after building the source, but with no avail.
Is there any known bug which causes Google Chrome tabs to crash?
Yes, I got it now.
From https://github.com/mozilla/pdf.js/issues/4104, I found the answer (thanks Rob and PDF.js dev team!). Take a look yourself!
I'm only posting this here so that anyone who stumbles upon this post with a similar problem can be helped (as this error took me quite a while to figure out).
Unfortunately, this does not seem to be the case. We've tried the latest version of pdf.js from github, also tried Chrome 33 (stable) which should have their V8 fix included and it still crashes. Also, tried the pdf.js commit mentioned in github thread (4ce6cb8 - https://github.com/mozilla/pdf.js/commit/4ce6cb8b0fa9db948516b2b738fa1503cf0ef90e) - still crashes. Also tried latest Chrome Canary available on 19/03/2014 - crash is there.
We can provide the WinDbg memory dump if it's of any help.
PS: sorry, this should be the answer to Rob W thread right above but I cannot add it there due to 0 reputation.
My problem may seem a bit vague (it is to me too), but here is my attempted explanation of it.
A few months ago, I implemented PDF.js in my web application. It was really useful, and I am using it for interactions with my clients.
Suddenly, last week, my clients reported to me "Aw, Snap" messages in Google Chrome on their PCs when they try to launch PDF.js. I have an iMac and two PCs at home, so I decided to test this out.
When I used Google Chrome on my iMac to launch PDF.js, I found it worked fine.
When I used Google Chrome on my first PC to launch PDF.js, I found it worked fine.
When I used Google Chrome on my second PC to launch PDF.js, even though it previously worked, it kept crashing and showing me "Aw, Snap" messages.
This was weird. I tried removing all the extensions, clearing the cache, clearing the LocalStorage, but nothing seemed to fix the problem.
I then realised, after some communication with my clients, launching PDF.js in Safari, Torch, Opera or Firefox on any operating system worked perfectly fine.
Why would this happen? I am using the web viewer in PDF.js. I also tried with the basic hello world example, but that broke as well (which I now find really weird), so I suspect there's something wrong with the rendering engine.
I also tried including the compatibility.js file after building the source, but with no avail.
Is there any known bug which causes Google Chrome tabs to crash?
Yes, I got it now.
From https://github.com/mozilla/pdf.js/issues/4104, I found the answer (thanks Rob and PDF.js dev team!). Take a look yourself!
I'm only posting this here so that anyone who stumbles upon this post with a similar problem can be helped (as this error took me quite a while to figure out).
Unfortunately, this does not seem to be the case. We've tried the latest version of pdf.js from github, also tried Chrome 33 (stable) which should have their V8 fix included and it still crashes. Also, tried the pdf.js commit mentioned in github thread (4ce6cb8 - https://github.com/mozilla/pdf.js/commit/4ce6cb8b0fa9db948516b2b738fa1503cf0ef90e) - still crashes. Also tried latest Chrome Canary available on 19/03/2014 - crash is there.
We can provide the WinDbg memory dump if it's of any help.
PS: sorry, this should be the answer to Rob W thread right above but I cannot add it there due to 0 reputation.
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.