sourcemaps + remote debugging issues #2183

[sofianhn]

I was trying inlined sources with remote debugging and noticed some issue with sourcemaps. I went back to try out regular sourcemaps with remote debugging and hit issues as well.

Basic scenario
Get the repro from here.

On machine A (MAC)

• cd ~/src/tmp
• tsc
• node --debug app.js

On machine B (Windows)

• cd c:\src\tmp
• tsc
• configure remote debugging
  "address": (A IP Address),"remoteRoot": "/Users/Sofian/src/tmp", "localRoot": "${workspaceRoot}"

Actual: I am attaching correctly, I am able to debug but that only works for .js not the .ts files.
Expected: I should be able to debug in my ts source.

Advanced scenario
this is even cooler.

On machine A (MAC)

• change tsconfig by adding "inlineSources": true.
• uncomment debugger from https://gist.github.com/SofianHn/14f261fe62789c6e4453#file-app-ts-L9
• node --debug app.js

On machine B (Windows)

• cd c:\src\
• mkdir test
• code .
• configure the debugger to an attach profile without specifying local and remote root.

Actual: the debugger connects the sources are streamed, even without having them in the local machine. But when I change the debugger profile to allow sourcemaps, I can't get the debugger to stream the TS sources.

Expected: It will be super cool if actually the debugger can stream the TS sources. I was able to get it to do this locally by deleting the TS sources without deleting the sourcemaps, it did the right thing by opening a read only TS file. That can be very helpful for debugging live websites.

Either way, this is really cool :)

[jin-syd]

Hi,
I have similar issue if I try to remote debug (Node+TS running at Ubuntu) at Windows VSC v1.2.0.
When I set break point at TS code, Break point moves to the above position.
I've tested it with the sample codes from Typescrpt offical web site.
Just FYI, I've attached the screen below:

If it works, I only need headless Ubuntu server and I can do all code work at Windows (again!!!).
Could you please push it up on the priority list?

Thanks,
Jin.

[weinand]

@jin-chong Where do you keep the source maps? Are they inlined in the generated code? If not did you verify that the source map is up to date?

[jin-syd]

Thanks for your reply Weinand,

Yes, I get up to date Sourcemap.
I found this issue while I'm developing my project, then I've tested it again with the imageboard sample application of TypscriptSamples from https://www.typescriptlang.org/samples/index.html.

I've compiled it by tsc and I cannot find inline sourcemap option of tsc, so I just set "sourcemap: true" at tsconfig.json.
I've put the codes on https://github.com/jin-chong/VSC-remote-dbg-test
It already has *.js.map as well.

You can test it like below:

1. Download or clone source codes onto Ubuntu(I've tested on Ubuntu 16 but it should be the same with other ubuntu version). Node version is LTS (4.x)
2. The codes already have *.js.map. However you can rebuild by just run "tsc" as this original readme.md says.
3. run "npm install"
4. run "node --debug-brk app.js"
5. On Windows computer (In my case, I've connected Ubuntu directory using Samba as network drive, but you can just copy files on to Windows directory ), open copied/shared source directory by VSC.
6. Put your Ubuntu IP address to "address" field, and Ubuntu src directory to "remoteRoot" field at launch.json on .vscode.
7. Run "Attach" debug. VSC will show you app.js. Open app.ts and try to set break point at line number 18. It will move up to 15.

FYI, when I simulate remote debug at the same Ubuntu ( by set "address" to "localhost"), it works fine.

Weinard. I love Windows and really want to run VSC on Windows but I have to run demon on Ubuntu.
I hope it is just my mistake or that would be great if there is any workaround before it gets it fixed.

Thanks a lot!
Jin

[delfinof]

Still problems with 1.2.1.

You set breakpoint in the .ts file, the debugger stops when the breakpoint is hit, but the "red dot" in the ts file is moved to the corresponding line in the js file.

How we can help?
I have a test project running with docker for windows + vscode in case you need it for further investigation.

[weinand]

@delfinof it would help a lot if you could produce a screen recording that shows what you are doing and how and when the "red dot" moves.

[weinand]

Remote debugging scenarios with source maps are a bit special and VS Code support for this is weak.
Some tipps and tricks:

• VS Code can only find source maps for remote files if the source maps are inlined in the generated files. Use "inlineSourceMap": true in your tsconfig.json.
• keep a copy of the generated JavaScript file (with the inlined source map) in the local workspace so that VS Code can more easily map breakpoints from source to generated file.
• use the remoteRoot attribute to map remote paths back to local paths.

[delfinof]

I guess the bug linked by me above, related to the node.js debugger extension, describes the same problem.

I prepared a simple project here for easily testing the "jump in breakpoints" via Docker for Windows / Mac.
https://github.com/delfinof/debugging-in-docker

My guess is that via the debugger, visual studio code receives some kind of update to the position of the breakpoints, and thinks they are relative to the "typescript source" instead of the "compiled javascript".

It is worth nothing that:

• it happens only when attached to a remote instance. Attaching to a local running process does not produce any problem
• it doesn't seem to be related to path separators, since it happens on Mac debugging Linux too.

[weinand]

@delfinof thanks a lot for creating that example project in github. With it I was able to reproduce and understand the problem.

The issue is unrelated to Docker and will occur in any setup that uses source maps and remoteRoot:
After registering a breakpoint in node.js VS Code tries to map back the actual location in the generated code to the original source. This mapping fails because the remote path is not converted into a local path first. And the fall back for the failed source mapping uses the location in the generated code instead of the original location in the source. This makes the breakpoints in the source jump to the corresponding location in the generated code.

Sorry about that.

The fix will be available in the next Insiders build.

[damiantp]

@weinand Thanks! We all that work with remote hosts in order to have a configuration server (say a VM, Docker container, etc) as similar as a production server will thank you for this fix.

[FredericLatour]

This thread is a bit confusing.
Is VScode supposed to work now when remote debugging nodejs typescript code using docker?
I spent hours on trying to get it right without any success.
I also tried to use the simple project posted by @delfinof and it doesn't work any better: the ts file isn't even reachable (greyed in vscode editor).
That's really quite frustrating.
Nobody developping (and debugging) nodejs/express/typescript apps using docker for windows and vscode?

[wnichols]

I have a (possibly unrelated) comment: I found that the debugger would fail to resolve breakpoints on linux. However if I caught the debugger on a panic stop I could open files on the stack and successfully put breakpoints in them.
The reason is that my home dir is a symlink. The situation was resolved when I set GOPATH to the fully qualified directory of my home and go source dir. Previously it had started with the symlinked directory.
wcn

[weinand]

@wnichols by default node.js resolves sym links which results in the failing breakpoint matching. Try launching node.js with the "--preserve-symlinks" option.