I'm investigating the possibilities to set up a breakpoint instantly when debugging JavaScript
for (...) {
for (...) {
...
}
// need a breakpoint here
}
The problem here is that a breakpoint cannot be toggled on comment line, it needs a statement.
And when debugger statement is added to line, another problem appears - it doesn't switch to Debugger tab automatically. It just looks like the application is pending, with no indication.
And I'm trying to avoid adding dummy statements because they can be neglected (as for debugger, there is at least an inspection rule to highlight it).
Are there any tricks to achieve this? Can debugger statement be made to behave like usual breakpoint at least?
Speaking to the general question, there is only one answer, and it is the one you do not want to hear:
You must have a statement for the breakpoint
There are no tricks that are widely applicable (although there may exist some IDE that allows for convenience breaking immediately after a loop... weird)
Unfortunately, what you want is typically done with a temporary/dummy statements (exactly the kind that you are trying to avoid):
for (...) {
for (...) {
...
}
// TODO: editors like Eclipse flag TODO lines so they are not lost in the source forest
setTimeout(Function.prototype, 10000);
}
This is due to the mechanics of how (most) debuggers work: basic file and line numbers are stored as debugger information (hints) in the compiled code, and then matched up with the available source during debug execution. For non-compiled languages like JS/PHP, similar techniques are employed with the string that is parsed from source, but lines with comments or brackets are not really executable.
This issue has occasionally reared its ugly head during my own developer journey. It is simply part of the nature of debugging. I hope you can find a coding solution that provides you comfort and some peace of mind.
Related
I'm learning v8 now, but I have encountered some problems.
How to set a breakpoint a method's start address in memory if I want to debug a method's C++ implementation.
e.g. var a= new Array(0,1); a.indexOf(1) ; I want to set a breakpoint at slice's beginning, or are there other ways to track the assembler code ?
There are a lot of functions will be complied and writed into a file named snapshot.bin. so I can't set a breakpoint at the beginning of these functions.
You need to check the source code and find the implementation of slice. Then set a gdb/lldb break point in that .cc file: byiltins-typedarray.cc
A lot of functions are defined as builtin or runtime functions.
It depends on the kind of function you want to inspect.
You can compile without snapshot to get around snapshot-related debugging difficulties (at the cost of making startup quite a bit slower: several seconds in Debug mode).
You can modify the respective code generator to emit a break instruction at the beginning of the function. For the example of Array.indexOf, that's probably the easiest solution; the CodeStubAssembler instruction is called DebugBreak().
You can break somewhere else using GDB, find your way to the function in question (e.g. via isolate->builtins), and set a breakpoint on the address of its entry. (This requires a bit of V8 knowledge and/or code reading skills, but it's not difficult.)
You can use various --print-*-code flags to print code to stdout (without breaking on it).
I have two programs that should be running the same . They are not. I'd like to see where their execution diverges. Is there an option in Chrome or Firefox or Safari to log/echo every line of JavaScript as it is executed ? Or some other way to do this short of manually adding console.log every few lines? Note: the divergence is 10k or 20k maybe 100k lines deep and ideally I'd want it to print variables similar to the Chrome dev tools.
Then I can just dump the logs and find the divergence
Stepping through the code in the debugger is not a solution as it would take hours if not days to step that far.
One idea is to use a babel or uglify plugin to use the last to emit code for each line to print what it is about to do or just did.
Another idea is if there is a way to dump all of memory from js so I can compare all objects and all references. They should be the same so when I see two dumps that differ I'll have found my bug. note: JSON.stringify is not an option as I need to see all variables/objects/classes etc.
Note: I'm not looking for basic answers like "use console.log" or "step in the debugger". I appreciate the help and maybe I've overlooked something simple but I do have quite a bit of JavaScript experience.
Maybe an example would help. Imagine you got the source to an app as large as google docs. You run some processor over it that's not supposed to break anything or change anything. Except it does. You look at the changes and can't see anything wrong. All you know is when you run it it runs but a few things are subtly broken. So you put a breakpoint there and see the data is bad. But when did it go bad? You don't know the code (you just got it). It could have been 100s of thousands of lines before. You have no idea where to put breakpoints or console.logs. It could take weeks. But, given you know the code should run exactly the same if you could print all lines of execution you'd find the bug in minutes instead of days.
You can add debugger; at the begin of the function() or where you want and open the console.
When the debugger is reached it stop the execution. After that you can execute code step by step and add some watches.
It works fine with all recent browser.
Example :
function test()
{
var rand = Math.random();
debugger;
return rand;
}
test();
It is node js but it may be helpful for you. set the NODE_V8_COVERAGE environment variable to a directory, coverage data will be output to that directory when the program exits.
https://blog.npmjs.org/post/178487845610/rethinking-javascript-test-coverage
I try to optimize the performance of a node.js application and therefore I am analyzing the behavior of V8's JIT compiler.
When running the application via node --trace_deopt --trace_opt --code_comments --print_optcode ..., the output contains many recurring lines like the following:
[didn't find optimized code in optimized code map for 0x490a8b4aa69 <SharedFunctionInfo>]
How can I find out which javascript code corresponds to 0x490a8b4aa69?
The full output is available here.
That error message used to be around line 10200 of v8/src/objects.cc, but is no more. It basically means no optimization was currently employed for a particular trace. Possibly because it was unused, or used sufficiently infrequently. It may have likely been a Node.js library function. The address provided is in memory. You'd have to have attached a debugger to v8 and load the symbol for the SharedFunctionInfo at that location. Possibly breakpoint on the line that produces the message too.
I don't think it is that useful to know what was not optimized, as there are lots of things that don't get optimized... just take the output from --trace_opt and assume everything else isn't. It was kind of just a hint that a check was performed for optimized code, and none was there are the time. Maybe try --trace_codegen and work backwards.
This looks to be a very time consuming thing to research.
Thorsten Lorenz would be the guy to ask about this.
I'd like to set a breakpoint in a "Cart.add" function in the Chrome or Safari JavaScript debuggers. Problem is, this function is defined in a large minified JS file, and doesn't exist on a line by itself.
Some documentation says that the WebKit-based debuggers support "break" or "debug" commands in the debug console, but those don't seem to work in newer versions of the debugger.
Setting a breakpoint on that line of the JS file doesn't work either, since there are lots of functions on that line.
Any suggestions?
In Chrome when you open Scripts tab you can prettify selected file by clicking on { } button ("Pretty print") at the bottom. After that you can find your line and set a breakpoint. The code will remain prettified with breakpoints in place after a page refresh.
The debugger statement is probably what you're looking for.
Evaluating the DebuggerStatement production may allow an implementation to cause a breakpoint when run under a debugger. If a debugger is not present or active this statement has no observable effect.
The production DebuggerStatement : debugger ; is evaluated as follows:
If an implementation defined debugging facility is available and enabled, then
a. Perform an implementation defined debugging action.
b. Let result be an implementation defined Completion value.
Else
a. Let result be (normal, empty, empty).
Return result.
The break statement is for exiting loops and switch statements and has nothing to do with debugging.
The real solution though is to not bugger your code in the first place :)
1) The error message should give you a link to the source code in the
Sources tab. Click on that link to get taken to the transpiled code.
2) Click the "{ }" icon at the bottom of the source code in the
Sources tab to format the transpiled code for easier debugging.
3)Stick a breakpoint at the line that is failing.
4) Reproduce the
problem again. This time, it should break at the breakpoint before
the error occurs.
5) Examine the local variables and call stack to
determine what exactly is going wrong.
For chrome users, you'll want to enable automatic pretty print in the experimental features.
setting your breakpoint should work now.
If you have saved the webpage then beautify your js file using jsbeautifier.org which formats your entire script. Then replace your js content with the beautified version. From here you can debug your JS easily
First of all, I've been researching this "Operation Aborted" error / bug for what seems like weeks, so here are a couple related questions and good articles if you are not familiar with it:
Why does ASP.NET cause the “Operation Aborted” Error in IE7? (so question)
Detecting cause of IE’s Operation Aborted Issue (so question)
Official Microsoft Knowledge base
Official IE Blog
Now here's my problem:
First I tried moving all my <script> elements to the end of my body tag. Didn't work. Then I refactored all my js functions to an external file that is linked in the <head>, all of my js functions are called from onclick or onkeypress anyway. Still getting the error. The last line of one of my .js files is
document.onload = setTimeout("foo()",500);
so I moved that to <body onload="setTimeout('foo()',500);">. I'm still getting this error. I don't know what to do. The only place I'm editing DOM elements is in foo(). Please help!
About my setup:
Java, Hibernate, Struts, JSPs ... I think that's all that is relevant.
What am I missing here?
Thanks in advance.
There are several causes for this. Two of the most common are:
1) scripts attempting to modify the DOM before the document has completely loaded
2) Trailing commas in object or array declarations
Number two is usually relatively easy to find, while number one is much tougher. Generally the best way to track down IE Javascript problems is to install Microsoft Script Debugger, so at least you can see what lines are causing the problem. With Script Debugger, IE will halt execution inside the browser and kick the script to a Script Debugger console, which will show the problem line. Much more informative than regular IE error messages.
Please see my answer to this question in another thread. I love this little trick and it has never failed me (when the cause is DOM manipulation before IE is ready, I mean). And as written, it doesn't affect the DOM-compliant browsers.
That problem can be a bear on a large page. Beyond the advice in the articles you already have, the only thing I can suggest from here is to remove wide swaths of the page in a dev environment until the problem goes away. Keep refining what is/is not on the page until you know which piece of content is causing the problem.
I've actually seen a confluence between two unrelated page elements cause this problem. I don't remember excisely why but the above approach, although painstaking, still worked.