I have more general question on how you usually approach on debugging page with tons of javascript (mostly third-party add-ons) and event watchers to discover the problematic line, which in my case causes the Chrome to crash or Firefox to freeze?
I have a landing page with many external dependencies: the usual suspects like jquery and bootstrap, but also many add-ons like sliders, re-size watchers. When I re-size there is a micro-freeze on Firefox and a crash on Chrome. This is from any block of code (some watchers most probably).
After page crashes I lose all of my dev tool data. Firebug doesn't have the timing control over scripts execution, and if I start with breakpoints I have to put dozens.
How you usually proceeding to identify the script that causes the problem and further more the block of code?
If I start with breakpoints I have to put dozens.
I used to have this problem a lot back with Internet Explorer 4/5. Those browsers made such poor use of memory that almost any significant error wold result in the browser crashing. And even before it did, the browser debugging tools were far, far worse than the Chrome ones. So what did I do? Sadly, debugger and console.log.
You must have some idea, or ideas, as to where the problem lies, so just start at wherever you are certain your code is working and add a console.log (if you can still see the logs up to the crash) or a debugger (if you can't) to every point along the way to the crash. Eventually you won't make it to one of your debugging statements, and then you'll know that the problem is in-between that statement and the previous one.
It's a really lame way to debug, I know, and as you said you will have to add a lot of debugging statements, but sometimes it's all you have.
Related
From what I can tell about this message, it appears when the driver encounters an error. The implication seems to be that the JavaScript code can't trigger this warning even if there's some kind of mistake in it, because of higher-level error checking.
But my code recently triggered it, just once and I haven't been able to reproduce it (and the code — in theory at least — sends the exact same commands to WebGL every time). So I just want to know if I should be debugging my code (I can't see any obvious errors), or if I should put it down to a hardware random / browser bug.
I can post semi-reduced code on request, but it's still about half a thousand lines and I certainly don't expect people to debug it for me, hence the more general is-it-possible question.
I'm struggling a little with what your question means by "trigger". When this error occurs, javascript is always in the causal chain, because WebGL doesn't run without javascript executing it, right? So certainly it's possible to trigger the error accidentally (unless you always trigger it on purpose, which I'm sure is not the case).
However, graphics drivers are notorious for being affected by many factors that are not under programmer control or necessarily detectable by the programmer, and therefore seem non-deterministic. That's why Google recommends that you try reloading the page when the error occurs. (A link to their guidance was here, but they moved or removed the page.) I've often had Chrome successfully display some WebGL after reloading a page, when the previous attempt ended in the "snag" error. (And I know you're aware of that.)
There are certainly times when WebGL code (like the various shaders on http://shadertoy.com/) work fine on some machines and not others, and work fine one minute and not the next, on the same machine. So that suggests that the "snag" error doesn't necessarily imply that your code is at fault.
However, articles like How to write portable WebGL can help you minimize risky practices in your code, and reduce the frequency of these errors.
The project I'm working on involves a "planning" screen, which is entirely made with backbone.js (the other pages of the app are not).
My issue is that from times to times, chrome freezes and the web view stop responding to any interaction. Sometimes, I can manage to quit chrome itself, but usually the controls does not answer either.
I'm pretty convinced this is related to the js code. It seems to me that when a script takes too much time, or loops indefinitely, Chrome can detect this and interrupt the script. However, since this is not the case, I'm thinking that too many js objects stay in memory.
Whatever the cause is, I would like to know which chrome dev tools can help me here. While I'm not a beginner in js, asides setting breakpoints and calling console.log, I have no idea how to debug JS apps. I'm not opposed to use another browser if the dev tools are more suited.
Thanks a lot for your time !
FTR : This is a rails 3.2.8 app, using mongodb, & Backbone.js 0.9.2. The js code is written in coffeescript. This issue happened on my macbook air 2012 running mountain lion, as well as on the client machine which runs on windows 7. The issue appeared at least on chrome 22 & 23.
Using the Javascript CPU profiler, I was able to find the group of functions that seems to be responsible for the freezing.
I'm still open to any advice/ressource on debugging javascript code.
Make a console.log in the loop and check if its the same point freezing on all chrome versions. There is a limit see Browser Javascript Stack size limit.
Maybe add some code? Because there could be some memory leaks especially with event handlers!
What I would do is the long and weary approach to getting your hands dirty with console.log. --- in this case.
In your case, and THX for the hint by the way (finding the offender with the CPU profiler, I'll try that next time round), I guess the offenders might be some functions "callbacking" themselves .. probably via some sort of event-handling/bubbling/callback-combination.
What happens then usually is that it just doesn't recognize the endless-loop, because the callback-stack is kinda "broken". Therefor it will never throw a browser-error.
If you have any luck, it doesn't kill the browser quick enough to kill the console. I did have that at times, the console killed (remaining silent), the coffeescript files not even loaded in the debugger (I use a JIT-coffee-to-js-translator as in JS-MVC) ... the page frozen or not doing anything ...
So, if indeed you are lucky and the debugger spits out your console.logs you can thereby guess where your unwanted loop is hiding. Just by looking at the repeated order of the output statements.
of course you know you can set breakpoints right? even conditional breakpoints
I'm currently struggling a bit untangling a similar sounding loop - i guess in case of emergency some alert() calls in your code would at least slow the loop down
or maybe some wait calls (bad idea)
my loop is running so fast I loose my console log!
I am in a middle of creating a website where we need to use a lot of script work. But due to extensive data load as we are loading the listing for youtube the browser hangs up due to unresponsive script error.
The data is being loaded using AJAX.
Can any one suggest how to tackle this issue?
Your suggestions will be highly appreciated.
Thanks in advance
J
You can change the dom.max_script_run_time and dom.max_chrome_script_run_time values, but it means the warning comes less often.
The best thing that you can do just find the root of the problem. I think you use Firefox, so if the script runs too slowly and long just click the Stop Script button and go to the error console.
More info are here.
Without knowing details, I can offer only these generalizations. Maybe one or more will help:
The jQuery .ajax call takes an option to make the call synchronous. That, combined with an unresponsive server, would cause the problem you describe. So, make sure you haven't mistakenly set that option.
On some browsers, FF at least, running out of memory causes an unresponsive script error. Chrome has a nice feature in which you can open a new tab, enter "about:memory" into the address bar, and a get a quick overview of how much memory other Chrome tabs/windows are using. See anything outrageous here?
On FF and IE, I have seen an infinite loop cause an unresponsive script error. Use a profiler, to detect this condition.
A profiler, like the one build in to Firebug for example, can help you pin down where in your script the problem is occurring. Knowing that, you can look for opportunities to break up the code into smaller operations. E.g., if you are processing a large amount of data, perhaps you could make a recursive call a setTimeout handler to process chunks of data at a time.
I've lately been running into odd issues, which I'm starting to think are related to resource starvation in the browser.
In FF:
I'd been testing one of our web apps and suddenly things that should disappear after a couple seconds stopped disappearing. I tracked back to setTimeout just flat out refusing to work. After reloading the browser it was all clear, no issues.
In IE:
I regularly see issues where IE will refuse to do transparency all the sudden, simply reloading the page clears this up.
In both:
Though I can't say its related for sure, I see unexplainable behavior, things along the lines of variables not being available (undefined) when they should be.
Both browsers also show a steady increase in memory usage over time (memory leaks).
The javascript in the web app is heavy and it is a single load page (making those memory issues mentioned all the more painful). There are lots of in-efficiency, and various things that make one say "why would you do that?".
Has anyone encountered such things? Can you point out general resources that will help identify and resolve these issues?
You could try running your application against the Chrome Profiler http://code.google.com/chrome/devtools/docs/overview.html. You can profile the CPU and get snapshots of the browser heap, that should help locate any rogue stuff.
If your application is designed to work with the Internet Explorer: The Developer Toolbar also has a profiler.
After an hour or two of heavy use on the site I'm developing, Firebug develops the following problems:
Breakpoints get glitchy -- it becomes difficult to add/remove breakpoints. Sometimes I click on a line multiple times, see nothing, move to the console tab and back, and then see my breakpoints again.
Console stops logging xhr's, or stops logging debug statements.
Script files become non-viewable.
I'm working with a javascript file which is quite large (over 10k lines). I don't think this is a memory leak issue with my own code. I'm refreshing the page all the time. Looks like an issue on the Firebug side. Is my logic sound? Is there anything I can do to get firebug to behave better? Or do I just need to restart firefox every hour?
Keep in mind Firefox while wonderful has always had many issues with handling memory. You should take a look at your task manager to see Firefox's memory footprint. Additionally I'd break up that JS file if you could into smaller chunks (for many reasons aside of this as well) to be better readable and work with the segments. Finally turn off plugins your not using or that may conflict with Friebug if your not using them.
I spent hours using Firebug without restart Firefox and never crashed, try a clean profile, install on it only Firebug and check if all works fine.
I use a separated development profile with Firebug and other dev oriented extensions installed.
How to configure a profile is described in many sites, on my wiki you find a brief description
i have similar problems! i think it is partially to do with the massive JS files. I just re-start firefox every once and a while. no big deal.