I have a fairly substantial application which i have been developing for a while and i have been able to debug things just fine.
However...
Yesterday i was trying to debug a specific piece of code which seems to break the dev-tools in chrome.
This specific piece of code is the onmessage-callback of a webworker. (Which, as i said, i have been able to debug before)
I have a switch-statement inside to determine which code to execute based on a message in the payload and the debugger only breaks for a specific message.
Any breakpoints i place outside of the callback work just fine but the ones inside (Even before the switch-statement is executed) result in halted code execution with most of the relevant tools disabled.
I have no call-stack, no scope overview, no variable contents when hovering over an identifier.
The breakpoint which got hit is shown under the breakpoint-pane highlighted but in the code window the blue highlight indicating which row of code is about to be executed is missing.
I seem to be able to add watches but that's about it except for resuming execution or single-stepping. (Allthough without seeing which row is about to be executed)
I have tried with chromium as well and some different versions of it but i always get the same result.
My intuition told me that my payload is too big and the debugger breaks because it can't allocate enough memory for the tools but the payload is small compared to payloads i have debugged before.
My question is, what could cause the debugger to break like this?
(Sorry for the lack of example code, there is just too much code required to reconstruct the scenario)
Related
I want to debug a website that is built from millions of lines of js code, and I want to find the function that will receive a specific value as one of the arguments. Is it possible to break the execution when any function receive a specific value as one of the arguments?
You could add a conditional breakpoint in
Chrome's debugger
Firefox' debugger
Alternatively, if the browser of your choice does not have similar functionality, you could invoke the debugger statement conditionally (if you can modify the code):
if(value === "wanted") debugger;
however that only works if you know the functions that might receive a specific parameter
Is it possible to break the execution when any function receive a specific value as one of the arguments?
No, that's close to impossible. Adding a breakpoint to "any function" will probably slow down execution a lot, if it's even possible. Doing so programmatically might work somehow, though it seems like a lot of work for little benefit. If you know the value, you probably also know the source and can debug from there.
var a = document.querySelectorAll('div');
console.log(a)
alert(11)
The browser first outputs the contents of the console, then alert
however,change the demo
var a = document.querySelectorAll('div')[0];
console.log(a)
alert(11)
The browser first alert, and then output the contents of the console, the same applies to document.getElementsByClassName, check for a long time unsuccessful, but also hope to answer
In "You Don't Know JS: Async & Performance" Chapter 1:
There is no specification or set of requirements around how the console.* methods work -- they are not officially part of JavaScript, but are instead added to JS by the hosting environment (see the Types & Grammar title of this book series).
So, different browsers and JS environments do as they please, which can sometimes lead to confusing behavior.
In particular, there are some browsers and some conditions that console.log(..) does not actually immediately output what it's given. The main reason this may happen is because I/O is a very slow and blocking part of many programs (not just JS). So, it may perform better (from the page/UI perspective) for a browser to handle console I/O asynchronously in the background, without you perhaps even knowing that occurred.
As you can see from the output, console.log(a) is actually executed before alert(11), except that the value of a is not displayed immediately.
After we click the OK button,
As you can see, the div tag is in the first line of the result. And the undefined in the next line is the result of alert(11).
Which tool is used to discover what JS/jQuery is consuming too many resources or in infinite loop?
More specifically I have an issue with this template: http://pages.revox.io/dashboard/latest/html/
Opening that page on Firefox 46.0.1 freezes the page after a few minutes. I'm unable to discover which JS/jQuery is causing this freeze with Firebug since it seems to be a script that is simply consuming too many resources and not in a plain freezing never ending loop (which would trigger the "Script XYZ is taking too long to execute" message)
Firefox 46.0 for Ubuntu appears to have a pretty good debugger built into it.
Using the system monitor it's easy to see your page requires a fair amount of memory.
It's fairly easy to produce a call graph in Firefox if you go to Tools->Web Developer->Performance and record your page for a little while.
Once you've stopped the recording, just select the data in the menu on the left and Call-Tree on the top of the debug frame.
It presents a breakdown of which functions use the most processor time.
Looks to me like whatever the Gecko function is, it is just really expensive.
Also, the console points out some interesting things:
mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create d3.v3.js:3:157
Use of getPreventDefault() is deprecated. Use defaultPrevented instead. html
Empty string passed to getElementById().
Maybe addressing the issues pointed out by the console will help your freezing issue.
Ok so I hope this is a question that isn't to basic for you guys.
I know enough jQuery to get myself into trouble, meaning I can grab elements and do stuff with it, write my own little functions for interactivity and such. But then something doesn't go as expected, before I post questions to stackoverflow and get answers that make me slap myself in the forehead I would like to debug it myself and am sick of inserting alert(); into my code. In reading up on the subject there is mention of console.log();, console.info(); and the such but I can not find any resource that explains how to use these in real world scenarios for debugging.
Do any of you know of a good resource or tutorial (not afraid to read a book) that can explain how to use these functions for the layman. It seems that the tutorials and such I am finding are either way to advanced or just skim the surface and don't show you how to use them. I understand I can insert console.log(); and it will spit out information in the console for firebug or element inspector. But what if my hand baked function is doing something unexpected somewhere up the line, how do I find the problem as the browser parses the javascript.
Any help would be greatly appreciated as I feel learning this will help me understand what is going on in my code, so I can stop staring at the screen going “Why isn't this working, it worked in the jsfiddle!”
console.log() just takes whatever you pass to it and writes it to a console's log window. If you pass in an array, you'll be able to inspect the array's contents. Pass in an object, you can examine the object's attributes/methods. pass in a string, it'll log the string. Basically it's "document.write" but can intelligently take apart its arguments and write them out elsewhere.
It's useful to outputting occasional debugging information, but not particularly useful if you have a massive amount of debugging output.
To watch as a script's executing, you'd use a debugger instead, which allows you step through the code line-by-line. console.log's used when you need to display what some variable's contents were for later inspection, but do not want to interrupt execution.
Learn to use a javascript debugger. Venkman (for Firefox) or the Web Inspector (part of Chome & Safari) are excellent tools for debugging what's going on.
You can set breakpoints and interrogate the state of the machine as you're interacting with your script; step through parts of your code to make sure everything is working as planned, etc.
Here is an excellent write up from WebMonkey on JavaScript Debugging for Beginners. It's a great place to start.
I like to add these functions in the head.
window.log=function(){if(this.console){console.log(Array.prototype.slice.call(arguments));}};
jQuery.fn.log=function (msg){console.log("%s: %o", msg,this);return this;};
Now log won't break IE
I can enable it or disable it in one place
I can log inline
$(".classname").log(); //show an array of all elements with classname class
Essentially console.log() allows you to output variables in your javascript debugger of choice instead of flashing an alert() every time you want to inspect something... additionally, for more complex objects it will give you a tree view to inspect the object further instead of having to convert elements to strings like an alert().
Breakpoints and especially conditional breakpoints are your friends.
Also you can write small assert like function which will check values and throw exceptions if needed in debug version of site (some variable is set to true or url has some parameter)
I have a website that suddenly started to crash internet explorer.
The website loads and starts executing javascript but somewhere in there the machinery explodes. I don't even get a script error, it just crashes. I've tried to manually step through every single line of js with the built in debugger but then of course the problem doesn't occur.
If i choose to debug the application when it crashes i see the following message.
Unhandled exception at 0x6c5dedf5 in iexplore.exe: 0xC0000005: Access violation reading location 0x00000090.
The top 5 items in the call stack looks like this
VGX.dll!6c5dedf5()
[Frames below may be incorrect and/or missing, no symbols loaded for VGX.dll]
VGX.dll!6c594d70()
VGX.dll!6c594f63()
VGX.dll!6c595350()
VGX.dll!6c58f5e3()
mshtml.dll!6f88dd17()
VGX.dll seems to be part of the vml renderer and i am in fact using VML. I'm not suprised because i've had so many problems with vml, attributes has to be set in specific order, sometimes you cant set attributes when you have elements attached to the dom or vice versa (everything undocumented btw) but then the problems can usually be reproduced when debugging but not now :(
The problem also occurs in no plugin-mode.
Is there a better approach than trial and error to solve this?
Edit:
Adding a console outputting every suspect modification to the DOM made the problem only occur sometimes. (the console is also implemented in javascript on the same page, i'm able to see the output even after a crash as the window is still visible) Apparently it seems to be some kind of race condition.
I managed to track it down even further, and it seems to occur when you remove an object from the DOM too quickly after it's just been added. (most likely only for vml-elements with some special attribute, didn't try further) And it can't be fixed by adding a dead loop in front of removeChild(pretty bad solution anyway), the page has to be rendered by the browser once after the addChild before you can call removeChild. sigh
(old question but important one)
I had a very similar problem - including lots of complex VML (from Raphael), and it looked near-impossible to debug.
Actually, it turned out the simplest low-tech approach was the best. It's an obvious approach: I'm writing here because sometimes when faced with an intimidating problem the obvious, simple solutions are the last a person thinks of.
So, simple old-school debugging: Lots of alert("1");, alert("2"); etc before and after every remotely demanding or complex call in my code, giving super-simple reliable breakpoints that don't rely on any features (e.g. developer tools) that might themselves crash out. Then, just see which number alert you get to before it crashes - the problem must arise between that alert and the next one.
Add more alerts until you narrow it down to the exact line. In my case, it was actually nothing to do with the complex VML - it was a for loop that, for some reason was continuing infinitely only on IE7.
Stop using VML?
If you need stuff in IE that really can't be done by moving, scaling, cropping and replacing images, then consider using Flash, Silverlight or similar.
If your life depend on VML then read as much as possible about other peoples experience, that may ease the trial and error approach.
Its a null pointer dereference non exploitable crash
Make sure that your scripts are running after the DOMReady event occurs. IE is notorious for crashing when modifying the DOM before it is fully loaded.
In some instances IE might prematurely fire the DOMReady event. See more information on how to overcome this here and here.
Are you using JSONP in any form? Popular implementations like jQuery tend to try and clean up memory by deleting the script node from the DOM after it has run. I've seen that crash Internet Explorer in many cases. Never could figure out what other conditions needed to be around to cause that to crash. Too much stuff going on in my other pages.
Anyhow, if you're using jQuery.getJSON, check the following line in jquery source:
(line 5556 on jquery 1.4.3):
} else {
// Garbage collect
window[ jsonp ] = undefined;
try {
delete window[ jsonp ];
} catch( jsonpError ) {}
}
if ( head ) {
head.removeChild( script );
}
You can safely remove that, or conditionalize it to only happen in non-IE browsers.
Hopefully that helps.