Breakpoints not working in debugging a vscode extension

[kdvolder]

• VSCode Version: Code 1.19.3 (7c4205b, 2018-01-25T10:32:23.601Z)
• OS Version: Linux x64 3.13.0-141-generic
• Extensions:

Extension	Author (truncated)	Version
vscode-boot-java	Piv	0.1.3
vscode-boot-properties	Piv	0.1.3
vscode-bosh	Piv	0.1.3
vscode-concourse	Piv	0.1.4-201802010127
vscode-manifest-yaml	Piv	0.1.3
java	red	0.18.1
vscode-java-debug	vsc	0.6.0
vscode-java-pack	vsc	0.2.0
vscode-spring-initializr	vsc	0.1.0

---

Steps to Reproduce:

1. Generate a brand new vscode extension using the yo code generator
2. Place a breakpoint on line 12 in extension.ts
3. Press F5 to launch debugger
4. In the launched vscode instance, press CTRL-SHIFT-P and select "Hello World" command

=> Observe that...

1. Extension is activated message 'Congratulations....' is printed in DEBUG CONSOLE
2. The Debugger did not stop in the breakpoint where this message is printed.

Note: I have also tried to make set

 "stopOnEntry": true,

In launch.json, but also in this case the debugger doesn't seem to work at all. I.e. the process just runs and doesn't stop anywhere, not on entry and not on any breakpoint I have put.

I first observed this in one of my own extension, trying to debug it. Then I verified it with brand-new generated 'sample' from the yo-code generator.

I can attach the generated project (didn't make any changes to it though, just generate, put breakpoint and run). Or let me know if there's any other information that might be useful and I'll do my best to provide it.

Reproduces without extensions: Yes

[kdvolder]

Attaching a screenshot showing active breakpoint and 'proof' that corresponding line of code was indeed executed (output in debug console).

PS: I also tried putting a breakpoint directly in the .extension.js file rather than the typescript source. That breakpoint also doesn't trigger.

[kdvolder]

Attaching a .zip with the 'toy project'. I just zipped up the directory and then deleted node_modules to save some space. Need to run npm install to get them back.

my-new-extension.zip

[auchenberg]

Hi,

First, thanks building an extension! In your package.json you have defined

    "activationEvents": [
        "onCommand:extension.sayHello"
    ]

this means that we'll first activate your extension if this event is triggered, so if you set a breakpoint inside activate method it will only get invoked when the sayHello command is executed from the command pallette.

If you had the following

	"activationEvents": [
		"*",
		"onCommand:extension.showNetworkTool"
	]

your extension would get activated when VS Code starts up, but we don't recommend this for performance reasons. An extension should only get activated when it's used.

[auchenberg]

I just pulled down your project, updated the launch.json to

        {
            "name": "Extension",
            "type": "extensionHost",
            "request": "launch",
            "runtimeExecutable": "${execPath}",
            "args": ["--extensionDevelopmentPath=${workspaceRoot}" ],
            "outFiles": [ "${workspaceRoot}/out/**/*.js" ],
            "preLaunchTask": "npm: watch"
        },

and is able to break when your command is run:

[weinand]

@kdvolder I've installed your my-new-extension.zip on ubuntu 16.04, ran npm install, opened the project in VS Code 1.19.2, set a breakpoint in line 12, and pressed F5.
In the new window I pressed F1, then typed "hello.." and "Return" which immediately hit the breakpoint.

So your problem does not seem to be easily reproducible.

• What type of linux are you using?
• Can you repro this when running code --disable-extensions?
• if you set another breakpoint in line 21 and then run the "Hello World" action, do you you hit the breakpoint? (a hypothesis: the breakpoint in line 12 is only hit on activation very early in the startup process. It could be that the code line has already been executed before the debugger could register the breakpoint. For the breakpoint in line 21 this shouldn't be a problem).

[kdvolder]

My Ubuntu version is Ubuntu 14.04 LTS.

@weinand You may be on to something that this is timing issue of some kind. So it could be a race condition which would explain why its not easy to reproduce.

I put a breakpoint in line 21. The breakpoint did not get hit the first time I invoked the 'Hello World' command. I.e. execution passed right through it. However the breakpoint did get triggered the second time. Also the third time etc. Just not the first time.

It is worth mentioning that even the first time it was not 'very early in the startup process'. Because the plugin extension does not get loaded until the command is actually invoked. So the log message only gets printed when the command is invoked the first time. I.e. when I press 'CTRL-P' and execute the command. Typically this some time after vscode debug instance's startup.

It still seems some timing issue are at hand here though. Do breakpoints get registered dynamically only when a corresponding source file is loaded? If so, maybe the response to activate the breakpoint to this 'load event' is too slow?

@auchenberg Yes, I understand that you need to invoke the 'Hello World' command to activate the extension. And I would expect that is when the breakpoint should get hit, but it doesn't. At least not for me.

[kdvolder]

Also worth mentioning again the 'stopOnEntry' flag in launch.json seems to have no effect (i.e. whether I set it to true or false, the extension host doesn't get stopped). I'm pretty sure this used to work in the past. Not sure this is the same, related or different problem. I can raise a separate bug for that if you wish.

[kdvolder]

More info that may help... Following up on @auchenberg suggestion. I changed my 'launch.json' according to his example. Basically... I removed the 'sourceMaps: true' piece and 'stopOnEntry: ...' piece.

With this change the breakpoint on line 12 is still skipped, but the breakpoint on line 21is hit even the first time.

It also doesn't make much sense to me that I should remove 'sourceMaps: true'. These are typescript compiled to .js with sourcemap files generated on the side. So don't we need the debugger to make use of these sourcemaps?

[kdvolder]

Can you repro this when running code --disable-extensions?

Yes, as mentioned in original report, though it may be hard to see amongst all the other auto-generated infos.

[kdvolder]

More info.

I noticed that @weinand mentioned using VS Code 1.19.2. I think I'm using 1.19.3 (according to auto generated bits of the report).

Decided to give code-insiders a try as well. My breakpoints in the sample project work perfectly in code-insiders. Perhaps this means bug is already fixed? Or maybe its just different timings at play. 'stopOnEntry: true' still has no effect.

[weinand]

@kdvolder the default for 'sourceMaps' is true anyway. So removing that attribute from a launch configuration cannot have any effect.

Yes, trying Insider is always a good strategy as we are fixing issues all day ;-)

[kdvolder]

@weinand I assume you closed this because it works in Insiders?

Note however that stopOnEntry: true still has no effect, even in insiders. I don't really care about that as much (if breakpoints work early on) but it seems like a bug to me. Do you want me to raise as a new bug ticket?

[weinand]

@kdvolder yes, closed because it works in Insiders (and I assume in the upcoming January stable release as well).

Yes, please file a new issue about the stopOnEntry: true issue.