Debugging WebAssembly with node - node.js

Is is possible to debug a wasm module through node?
I am using vscode and compiling with emcc -g4 --source-map-base. Putting a breakpoint in the C source file is ineffective. Trying to debug with node inspector node --inspect through Chrome doesn't allow me to use breakpoints either, although it is possible to debug wasm modules from regular web pages in Chrome.
I am using nodejs v10.13.

WebAssembly Source Maps is supported by both Firefox Developer Edition (in screenshot) and Chrome 71.
What you forgot is, to include a path to the source map. For example:
emcc -g4 --source-map-base http://localhost:8000/
Every source files path is prefixed with http://localhost:8000/ with this option. So replace this with your source directory.

So, I managed to get something working. I installed:
Node v11.4
Chrome beta 71 (because of this)
And launched the node process with node --inspect, for attaching the Chrome DevTools.
Moreover, in my code, instead of doing WebAssembly.instantiate in one shot (supplying directly the bitcode), I do it in two steps: WebAssembly.compile first, and then WebAssembly.instantiate. As soon as compile gets executed, there are some "wasm" sources being made available in the DevTools. This is the WebAssembly in wast text form, in which breakpoints can be set before it gets executed by instantiate.
But you can't debug from the original C-source files, Chrome DevTools only shows the decompiled wast yet. This feels like the stone age of debugging, but it is still possible to debug.
Edit 2020: This article https://developers.google.com/web/updates/2019/12/webassembly seems to indicate you should now be able to debug in devtools, from the original C source files. I did not try it, though.

Related

Debugging ServiceStack’s react-lite and vue-lite

How can I attach a debugger to debug the typescript part (react/vue) of the new “lite” templates?
For regular SPA projects with npm there are two ways I know of:
either debug from VSCode - run SS and npm start and then attach to Chrome
debug within Chrome, as the typescript source maps are available somehow
With the new “lite” templates debugging the server-side is easy, but what to do with Typescript/React/Vue debugging? I tried to run SS from command-line, and then attach VS Code to port 5000, but the breakpoints won't hit (not even for the compiled JS files)
There’s no source maps support in the Vue/React lite Project Templates so you won’t be able to debug the original .ts source files and you’ll need to debug the bundled .js instead from Chrome’s WebInspector.

Chrome Devtools Dedicated Node.js Inspector not stopping at breakpoints

There have been a couple of older posts regarding this issue, but date from questions asked in 2013 and 2014 and the answers in there have not helped my case.
I have the debugger keyword placed in multiple places in my file, and have even added manual breakpoints in the inspector UI. Still, executing the file does not stop at any breakpoints. I am using node 9.2.0 and chrome 64.0.3282.167.
Here is a picture of how my devtools appears.
Use the --inspect-brk flag instead
I ended up opening up an issue on the devtools protocol github page.
I got an immediate answer. Basically, because I was using the --inspect flag to start the Node.js debugger, my JavaScript was being executed before the debugger process was connecting to the DevTools server. Therefore breakpoint information would be relayed too late and no breakpoints would be triggered.
Example: node --inspect-brk myscript.js
They're currently trying to improve this use case. Here's the actual reply:
We are working on better workflow here but for now --inspect-brk is
only one way. With --inspect-brk node waits DevTools frontend
connection. On connection DevTools send all breakpoints information
and starts JavaScript execution in node. With --inspect node starts
JavaScript execution without waiting for DevTools frontend. As soon as
DevTools connected, we send the same breakpoint information to node
but it can be too late since some JavaScript is already executed.
The Node.js docs are not very clear on this subtlety as of 4/6/2018. I will submit a PR on their repo to update the docs. BTW, if you are not aware, even without the V8 integration, the built-in debugger is very powerful. Explore all the possibilities of the debugging utility in the docs.
This is a problem that has been extremely annoying to me since 10.13 went to LTS and I upgraded from 8 to 10.
I was unable to find anything about this issue until I saw this question here on stack overflow, that was the catalyst I needed to be able find more about the problem and discover the cause and the solution.
You can find out more here: https://github.com/nodejs/node/issues/23693
The Why:
Basically it is because of a change to the debugger protocol in Node.
The Solution:
Upgrade Chrome to 71 or later which supports the change in the protocol.
Much Better Solution: Install NIM: https://chrome.google.com/webstore/detail/nodejs-v8-inspector-manag/gnhhdgbaldcilmgcpfddgdbkhjohddkj then go to the NIM settings and change the selected DevTools version to the one from chrome-devtools-frontend.appspot.com ( see more about this option here: https://june07.com/blog/nim-custom-devtools-url/ )
I have this issue too: Chrome Devtools Inspector not stopping at breakpoints.
My problematic software versions:
Chrome: Version 70.0.3538.77 (Official Build) (64-bit)
Node: v10.12.0
A workaround I found is to downgrade NodeJS to version 8.12.0 (the latest 8.x version). Node version 8.x works for me.
$ node -v
v8.12.0
I also tried Node version 10.13.0, 11.1.0, none of them works for me.
FYI: How to change Node version
The deeper reason seems to be that the debugger maintains two separate databases where it stores the breakpoints. Opening a file from the Sources tab, and setting breakpoints in it, is a waste of time. Maybe node considers these suspicious or unconfirmed -- whatever. They are ignored. These breakpoints are stored "somewhere" but not in the place that an active debugging session finds them or respects them.
You need to first manage to break the active execution of the source file that you want to debug, and then set the breakpoints while in a running context. You will notice that all breakpoints that you had previously set via the Sources tab have disappeared, and you can set new breakpoints. Only those new breakpoints are "observed" by node at runtime.
So the workaround today (September 2019) is as follows:
Pepper the source file you wish to debug with debugger; statements
Start your project with inspect-brk to force the debugger to stop the program before its first line is executed
Click the little blue arrow to continue execution normally; the debugger; statements should now break in the source file you are interested in.
Once you are stopped, you can set breakpoints that will actually be observed, and saved, in the "correct database" (for the lack of a better term).
I had the same issue today while working with 10.13.0. based on the comment from answer 4, I tested different versions with $ nodenv local <version> and I had the following results:
10.13.0 (not working)
10.12.0 (not working)
10.11.0 (working)
10.10.0 (working)
Assuming lower versions work.
If you're not familiar with nodenv, you can get it here https://github.com/nodenv/nodenv
I found that if I manually type:
debugger;
where I want the breakpoint to occur in my code then this actually fixes this issue for me.
e.g.
var counter=0;
while (true) {
for (i = 0; i < 5; i++) {
debugger; //enter this through Chrome Dev then press CTRL s to save
counter++;
}
}
I'm running the above via:
node --inspect-brk=0.0.0.0:5000 test_debugger.js
[The 0.0.0.0 is here due to this being on a remote server.]
I had a similar problem and found an easy fix. Instead of using chrome devtools, try node-inspector, which does the same thing - https://github.com/node-inspector/node-inspector#quick-start
Open node.js command prompt
Install the node-inspector package npm install -g node-inspector
node-debug <your-entry-point> replace <your-entry-point> with your 'main' file, usually app.js by default (remember to navigate to the full file location if not already there e.g. C:\Users..)
Wait for new browser window with node-inspector to open

How to properly develop/debug Chrome extensions

I just started developing my first Chrome extension.
Tutorials describe the process like this:
put code in a folder
load it into Chrome using Settings | Extensions
run it & use Chrome devtools to set breakpoints.
However, this seems like an extremely tedious process. I use WebStorm and would much rather start the debugging session from there and also set breakpoints in WebStorm.
I am sure there must be an option and developers do not manually load the extension in chrome after every change.

How to filter files from Node.js Debugger

When using the Node.js Debugger with Chrome DevTools it's desirable to only debug the code you have written, and skip over code in node_modules. This can be done by blackboxing node_modules. However Node.js's own javascript code is not clearly under a file path that can be blackboxed (as seen in the picture below). How does one filter all of Node.js's internal javascript code from being stepped through in the Chrome DevTools debugger?

Dart Angular2 on Nodejs debugging

The tutorial of angular2 with dart never actually uses a real server, always pub serve.
How can I debug my dart code when using a real server like NodeJS? Atm I'm just getting errors like a.b.Y is not defined(in the browser), which is completely useless.
Is there some kind of source mapping for dart2js?
Ok after building with pub build --mode=debug. The dart source is available in chrome dev tools (it shows "source mapped from main.dart.js" for all my dart files. Breakpoints are not stopping tho.
Sounds like the problem I had with another Dart library when I tried running in another server via NGINX. Is your pubspec.yaml properly set up?
My issue was that I wasn't using the transformers or entry_points section of the pubspec.yaml which generates definitions of start up classes.
https://stackoverflow.com/a/38284430/174368
Is your pubspec.yaml similar to the Dart Angular2 example below?
https://angular.io/docs/dart/latest/quickstart.html#!#add-config-files
Also make sure you serve the build directory via nodejs because it'll edit your index.html put it in the build directory and add automatically other link/script lines to include other files.
This might also be part of the reason you can't see your breakpoints. That happened to me too.

Resources