Smart Step marks code that should not be skipped, using ts-node

[srdjan-pepic-devtech]

Issue Type: Bug

SmartStep is skipping my files in a nestjs application. Debug is working correctly but no yellow line is shown on breakpoints in any of my files and I can see in call stack that my functions are hidden (as anonymous) and skipped by SmartStep.

VS Code version: Code 1.31.0 (7c66f58, 2019-02-05T22:35:56.624Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz (4 x 3292)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: unavailable_off surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Memory (System)	31.91GB (16.65GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (13)

Extension	Author (truncated)	Version
prettier-vscode	esb	1.8.1
javac-linter	fau	1.3.1
vscode-javac	geo	0.2.13
csharp	ms-	1.17.1
PowerShell	ms-	1.11.0
vscode-docker	Pet	0.5.2
material-icon-theme	PKi	3.6.2
java	red	0.38.0
vscode-java-debug	vsc	0.16.0
vscode-java-dependency	vsc	0.3.0
vscode-java-pack	vsc	0.5.0
vscode-java-test	vsc	0.14.0
vscode-maven	vsc	0.14.1

(2 theme extensions excluded)

[srdjan-pepic-devtech]

additional note: this does not happen on version 1.30.2

[roblourens]

It's not really clear what you are seeing... can you include a screenshot? Can you share the project?

[srdjan-pepic-devtech]

@roblourens I can't really share any of the code, bud I could try and make it more clear on what is going on. I am working on nestjs application. Since updating to version 1.31 from 1.30.2 I had trouble when running in debug mode. When running the application in debug whenever I hit my breakpoint the application stops at the right place, but vscode doesn't mark the line yellow (as it usually does) on the current line of execution, when i go to call stack window I can see few functions in call stack are "skipped by SmartStep". When expanding the skipped functions I can see that those are the ones with my breakpoints.

[kriffe]

Same problem here I tink. Something happened with 1.31.0 that broke debugging in editor. Jumps over lines of code irradically, doesnt show the actual debugging line in the editor unless call stack is clicked. Doesnt matter if its top level (like a mocha test) or farther down in sub libraries.

Also tried to disable smartStep in .vscode options without result. Never heard of the feature until now.

[FishOrBear]

me too 1.31

[roblourens]

Can anyone share their project where this happens? Or set "trace": true in your launch config, try it again, and share the log from the path that it prints in the debug console.

[kriffe]

Not so easy to share the code unfortunately. The log is over 9 MB in our case (possible cause?) and contains information not so sharable either unfortunately. Added a debug point in the mocha tests where the behaviour happens and copied the last rows

Last rows in log

[21:16:34.242 UTC] To client: {"seq":0,"type":"event","event":"output","body":{"category":"telemetry","output":"ClientRequest/stackTrace","data":{"Versions.DebugAdapterCore":"6.7.41","Versions.DebugAdapter":"1.31.5","Versions.Target.Version":"v8.9.4","successful":"true","timeTakenInMilliseconds":"32.966801","requestType":"request"}}}
[21:16:35.501 UTC] To client: {"seq":0,"type":"event","event":"output","body":{"category":"telemetry","output":"target/notification/onScriptParsed","data":{"Versions.DebugAdapterCore":"6.7.41","Versions.DebugAdapter":"1.31.5","Versions.Target.Version":"v8.9.4","aggregated.startTime":"[\"1549919785668\",\"1549919785831\",\"1549919785935\",\"1549919786349\",\"1549919786446\",\"1549919786598\",\"1549919786693\",\"1549919786784\",\"1549919786887\",\"1549919786890\",\"1549919787088\",\"1549919787225\",\"1549919787316\",\"1549919787406\",\"1549919787584\",\"1549919787732\",\"1549919787864\",\"1549919788078\",\"1549919788174\",\"1549919788445\",\"1549919789159\",\"1549919789273\",\"1549919789370\",\"1549919789637\",\"1549919789732\",\"1549919789833\",\"1549919790053\",\"1549919790158\",\"1549919790258\",\"1549919790614\",\"1549919790748\",\"1549919790916\",\"1549919791078\",\"1549919791271\",\"1549919791393\",\"1549919791598\",\"1549919791709\",\"1549919791813\",\"1549919791904\",\"1549919792130\",\"1549919792261\",\"1549919792395\",\"1549919792617\",\"1549919792789\",\"1549919792901\",\"1549919793090\",\"1549919793194\"]","aggregated.successful":"[\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\",\"true\"]","aggregated.timeTakenInMilliseconds":"[\"1.875401\",\"1.641001\",\"1.640201\",\"3.1042\",\"0.950099\",\"0.937899\",\"0.9574\",\"1.275199\",\"1.6403\",\"0.9408\",\"1.254001\",\"2.524401\",\"0.956999\",\"1.736601\",\"0.941499\",\"1.6808\",\"1.4908\",\"1.1235\",\"1.031599\",\"505.8049\",\"2.5918\",\"2.479299\",\"0.9636\",\"1.1964\",\"1.4413\",\"1.5975\",\"1.2239\",\"0.9894\",\"1.5919\",\"1.6403\",\"1.126101\",\"1.5516\",\"2.7745\",\"1.5067\",\"0.961301\",\"1.000701\",\"1.337099\",\"1.1463\",\"1.077\",\"1.410599\",\"1.587301\",\"1.634699\",\"1.099\",\"2.011001\",\"1.1579\",\"1.081899\",\"1.320599\"]"}}}
[21:16:35.502 UTC] To client: {"seq":0,"type":"event","event":"output","body":{"category":"telemetry","output":"target/notification/onPaused","data":{"Versions.DebugAdapterCore":"6.7.41","Versions.DebugAdapter":"1.31.5","Versions.Target.Version":"v8.9.4","aggregated.startTime":"[\"1549919793770\"]","aggregated.successful":"[\"true\"]","aggregated.timeTakenInMilliseconds":"[\"1.079399\"]"}}}

Also attached config file

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Local mocha",
      "type": "node",
      "request": "launch",
      "program": "${workspaceRoot}/node_modules/mocha/bin/_mocha",
      "stopOnEntry": false,
      "smartStep": false,
      "args": ["--require", "ts-node/register", "test/mocha/**/*.ts", "--no-timeouts"],
      "cwd": "${workspaceRoot}",
      "runtimeExecutable": null,
      "env": { "NODE_ENV": "testing"},
      "console": "integratedTerminal",
      "trace": true
      },

  ]
}

[roblourens]

I can't repro any real issue with this, but I do see that disabling it does not work properly. The next release will have a fix so that setting smartStep to false will correctly stop labelling the frames as smartStepped.

[roblourens]

Ok, now I can repro this. It's not a regression on the debug adapter side, but it's more noticeable in vscode now because vscode is not highlighting the current line when it grayed out. But it's not clear what the right thing is for vscode to do.

The debug adapter's issue is that the runtime js file and the sourcemapped file have the same name and .ts extension, and that causes some confusion. Trying to fix that, I run into #68480

Trying a simpler workaround, I try to change

frame.source.presentationHint = 'deemphasize';

to

frame.presentationHint = 'deemphasize';

but it seems that this isn't respected, is there a way to do that @isidorn?

[kgrvr]

So as of now, there isn't any way to disable smart step in settings.. Or some other workaround for this?

[roblourens]

"smartStep": false should work correctly in the next Insiders release in a few hours, and in stable in a couple days. Otherwise you should still be able to click the frame to focus that file. It just won't open it automatically when stepping. Which I understand is very annoying.

[FishOrBear]

So as of now, there isn't any way to disable smart step in settings.. Or some other workaround for this?

https://update.code.visualstudio.com/1.30.2/win32-x64-user/stable

[isidorn]

@roblourens I was on vacation, am I still needed for something here? If yes let me know what so I do not have to read the whole discussion from above

[roblourens]

#68480 should be fixed and I can look into that if it's easy.

I also had this issue:

Trying a simpler workaround, I try to change

frame.source.presentationHint = 'deemphasize';

to

frame.presentationHint = 'deemphasize';
but it seems that this isn't respected, is there a way to do that @isidorn?

to just fix the presentationHint on the top frame. I'm curious about that but #68480 is the main thing I will look at for a real fix for the next release.

[lonix1]

@roblourens When is the next release planned for? Debugging has become a colossal pain for many of us.

Appreciate you looking into this!

[isidorn]

@lonix1 The next release is planned for in about 2 weeks.
@roblourens looking at the code we do not treat frame.source.presentationHint and frame.presentationHint equally.
For example when checking what frames to collapse together we only check the presentationHint on the source here
Also when choosing what to gray out here

We can easily change both those places to also check the presentaitonHint on the stackFrame if that is what you really need also after you do the real fix.

[roblourens]

@lonix1 you can also set "smartStep": false which should help the issue.

[lostfields]

I have a similar issue to this, for each step over I have to click the first item in the CALL STACK to see the breakpoint in my code. It's like nothing has happened, but when I click the item in call stack VSCode will jump to the correct file and should all related variables in VARIABLES etc.

If I type this in the Debug console it also jumps to the correct file without clicking in the CALL STACK. Looks like there is a UI problem, not showing where the debugger is at right now.

Really annoying, using debugging through ts-node

Version: 1.31.1 (system setup)
Commit: 1b8e830
Date: 2019-02-12T02:20:54.427Z
Electron: 3.1.2
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

EDIT
"smartStep": false solved the issue

[bfancher-leanplum]

this defect is killing me. I'm using the Jest extension, so that I can run singular tests, but I can't figure out how to set "smartStep": false in this context, as I don't use the launch.json file at all for the jest extension...

My test files are rather large, so having to debug entire files again would be equally painful

[roblourens]

Would appreciate if everyone tries this in the next Insiders build (without the workaround of disabling smartStep). It should work properly now.

[roblourens]

Verification steps for my team

• Clone https://github.com/roblourens/repro68127
• Set a breakpoint in app.controller.spec.ts
• Close that file
• Start the launch config
• It should open that file and the top frame should be selected and not grayed out in the call stack

[dbaeumer]

The steps do not work for me. All I get is:

Additional steps I added:

• npm install
• npm run build

No luck.

[roblourens]

I removed the debugServer config @dbaeumer, sorry about that.

[tkrein321]

@roblourens I tried the latest insiders build and the original problem is somewhat fixed but still behaving incorrectly.

The breakpoint gets triggered, highlights the right line in the editor and the call stack is correct. However it doesn't open up the original source file. Instead it opens up a file that is named the same but contains the generated JS code. Next to the file name it says "read-only core module". Pic enclosed.

Note that I am using ts-node.

[roblourens]

Thanks for trying it @tkrein321, could you set "trace": true in your launch config, try it again, and upload the log here?

Alternately if you can share your project that would help a lot too.

[tkrein321]

Sorry, I can't share the project. Also I can't post the log file where it's public but I will email it to you.

[tnrich]

Also hitting this trying to debug someone elses code:

To Reproduce

clone this repo:

git clone https://github.com/tnrich/vscode-convert-object-to-jsx

And add a breakpoint at 216 or 220 to src/convertObjectToJsx.ts, and then run

yarn;


env "CI=vscode-jest-tests" your-path-to-node --inspect-brk=12543 node_modules/jest/bin/jest.js --runInBand convertJsxToObject.test.ts --testNamePattern "Converts object spread"

you have to fill in your-path-to-node in the above command.

My breakpoints aren't getting hit! You'll see that yours won't be either.