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.
Related
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.
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'm very experienced in C/C++/Objective-C and over the last few days have been trying my hand at html/css/JS and am finding it very frustrating.
Time and time and time again I've been caught out as I've a syntax error or undeclared variable due to copying / pasting etc. with the consequence being that the code suddenly stops working then I have to scratch my head and figure out why.
The most painful thing is resorting to sprinkling alerts in the code everything something fails in order to track down the reason. I know there is the new console object for logging but it doesn't seem to work with Komodoedit or jsFiddle? Which is what I've been using.
Is there a way of using these tool, or alternative tools where I can step through the code line by line in a debugger like I can with other languages? Or any tricks for easy detection of problems with the code before executing it in addition to jslint?
[I don't want to use any libraries that might have built-in support for logging etc. as I'm finding they (well JQuery/JQuery mobile is) are drastically slowing down loading times on an iPhone so want to concentrate on pure JS.]
[My target browser is just iOS, but am using Komodoedit with Chrome most of the time and every few hours try it on an iPhone]
Thanks
You need several tools.
First, get yourself a real debugger. I use the one built into Chrome. There's a similar one built into Safari and Firebug available as an add-on for Firefox. This will allow you to set breakpoints and step through your code and see exactly what is happening.
Second, get very used to running your code through jsLint. This will show you many obvious typos and encourage you to write robust code from day one.
Third, start writing in strict mode. This will again prevent some obvious typos and force you to start some good habits.
Fourth, use console.log() when needed. Once you have a debugger, it's output will show in the debug console of the debugger for any page in your browser, including jsFiddle pages. You will have to invoke the debugger on the right frame in jsFiddle and then it will work fine. I use both a regular debugger and console.log() all the time with jsFiddle. It takes a little figuring in jsFiddle and the debugger to find where your own code is to set breakpoints, but once you find it, it's easy to use.
Fifth, javascript is simply not C++. While the syntax will seem quite familiar, the way you do things with anonymous functions and closures and objects and prototypes is very different. As one who programmed in C++ for many, many years before learning javascript, I very much appreciate what I can do now in javascript that was a lot more work in C++, but it took awhile to get my brain into a new mode of thinking. I spent too much time in my first years of javascript development trying to emulate C++ techniques rather than just learning the better way to accomplish the goal in javascript.
Sixth, you will have to change how you write and test code because of the lack of a compiler that finds errors for you. I remember in the days of C++, when I needed to refactor something, I could make a bunch of changes and then let the compiler find all the other places I need to fix the syntax. You can't do that with javascript. When you make mass changes, you can run through jsLint to find some issues and then you literally need to execute every path to make sure everything works. It is a bit of a pain.
Seventh, find a strategy/tools for unit testing. Once a project gets more than a few functions long, you will benefit greatly from building unit tests that you can run anytime you make significant changes. They will both find issues for you in a lot less time than without the unit tests and they will give you the courage to refactor and clean up your code when you see the need for that because you know the unit tests will tell you if everything is working again. It's extra work up front that pays dividends many times over down the road.
Firefox has an add-on called FireBug that is very helpful for debugging CSS/javascript, and yes, it does have the ability to step through a script as well as a command line where you can try out various javascript expressions. I'm pretty sure Chrome has a similar feature.
Here is the article in which you get a list of tools to debug the javascript
advance-javascript-debugging-techniques
Since you're using Chrome, you just need to open the developer console (spanner -> tools -> javascript console, or Ctrl+Alt+J (at a guess)). Instead of sprinkling your code with alerts, use console.log, console.error, and console.info to print to it. All of those are variadic, so you can pass as much to one call as you need.
In addition to this, you can use the console to test and modify parts of your code on the fly, or to just try out a few snippets to see if they work. It's a fully functional REPL that also works with the current document.
In the sources tab of the developer console, you are able to set breakpoints and step through your code, analysing state at each point. This page goes into some detail about it: http://chromedevtools.googlecode.com/svn-history/r421/trunk/tutorials/breapoints/index.html
In the elements tab, you are able to set breakpoints on changes to elements in the DOM, including changes to attributes and child nodes. Right click a node and select the option you want. This will come in handy when debugging code that is asynchronous and plays with the document (eg. AJAX calls inserting new content).
In addition to this, you can scroll to the bottom of the styles pane to the right, and open the event listeners section. Here, you can inspect all the events bound to the selected DOM node.
You can enter debugger (without a semicolon) into your code, and it will open the sources tab at that point so you can inspect the code further. I think this may be Chrome specific.
Finally, tools like JSlint will help you spot undeclared variables as you code, as well as cases where the formatting of your code creates unexpected errors, and some might even go as far as using syntax highlighting to make you notice variables that are undefined.
This is also just scraping the surface. Your editor and JSlint can make your code look right and parse without error, but the browser and its console is where you will spend most of your time.
I'm having a bit of trouble with IE 8 (and probably all previous versions). Firefox and Chrome/Webkit are seemingly fine.
Something is causing page rendering, scrolling, and basically all page interaction to become blocked. As best I can tell, Javascript execution is causing this to happen.
Specifically, I think there are two major responsible parties in my specific situation - Google Maps API (v3) and Facebook Connect.
In both cases, I am using the asynchronous load methods provided by both Google and Facebook.
I've tried a couple of things so far, to no avail:
Delaying execution with jQuery's $(document).ready(). This just prevents the locking until slightly later in the page load. Actually, since I use gzip compression, I'm not really sure it does anything - I'm not clear on how that works.
Delaying execution with window.onload. Same situation - the whole page loads, then it locks up while it grabs and executes the Facebook Connect code.
Using setTimeout(function(){}, 0). I'm not 100% clear on how this is supposed to actually work - as I understand it, it essentially is supposed to force the execution of the function's code to wait until the stack is clear. Unfortunately, this doesn't seem to do much of anything for me.
I think the problem is especially exaggerated for me because I am on a slow connection.
I can't think of any specific oddities with my site that would be a factor, but I won't rule that out.
So, my question:
Are there any best practices or existing solutions to this issue?
Is there something that I am obviously doing wrong?
The offending site is at: http://myscubadives.com/, if anyone would be willing to take a look at the specific implementation.
Thank you in advance for your time and help.
Sam
Yes, the browser (at least IE) suspends itself while Javascript is being executed. This makes things a bit faster, because it doesn't have to redraw and recalculate layout every time you make a change. However if your Javascript takes a long time to execute, this will seem like freezing. Synchronous XMLHttpRequests also count.
Unfortunately there is no pretty workaround. The typical advice is to use window.setTimeout() function with timeout set to 0 (or something very small) to split the workload in several parts. Inbetween the browser can manage to redraw itself and respond to some user interaction, so it doesn't seem frozen. The code gets ugly though.
In case of lengthy XMLHttpRequests you have no choice but to use the asynchronous version.
Added: Ahh, I see that you already know this. Should read more carefully. :P Did you also know that IE8 has Developer tools built in (Press F12 to activate) and that the Javascript tab has a profiler? I checked it out, and 2 seconds were spent exclusively in jQyery's get() method. Which gives me a strong suspicion that something is still using synchronous XMLHttpRequests.
Function: get
Count: 10
Inclusive time: 2 039,14
Exclusive time: 2 020,59
Url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js
Line: 127
I have a web portal cricandcric.com which I have done using the php, java script, and mysql.
I dont see the java script error in Firefox, but i see the error in IE,
I observe the site loads faster in Firefox than in IE.
So my question, does java script errors can slow down the website loading time, even though the java script placed at the end of the page, (Yslow Strategies)
It depends. If the error happens early on and a lot of your script code is bypassed, it could actually make it faster. But every time an error occurs, there is some overhead (the exception object has to be built and sent up the call stack to look for any catches), so if it happens at the end, the script would run slower.
But I doubt your change in load time is noticeably impacted by script errors. How long the script takes to execute on the browser's JS engine or a host of other factors will have more impact.
IE's javascript engine has always been notably behind the other common browsers in performance, so it really might come down to that more than anything else. One of the many improvements in IE9 is JS execution speed that's actually competitive.
That said, the JS error probably is worth looking into, since it's occurring every time the image slideshow advances which happens once every couple of seconds.
If you're concerned about performance in general, there are a couple of tools like YSlow and the recently-opensourced DOM Monster bookmarklet, for giving suggestions on general ways to speed up websites. You might also want to check out some of the writings of Steve Souders.