debug - resume on stepping

[jrieken]

• windows
• create a JavaScript extension using yo code and have the code like below
• set a breakpoint in lines 22 and 34
• run, break, resume, break and from line 34 start stepping
• when you step over console.log(longString); the program resumes instead of stepping

// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
var vscode = require('vscode');

// this method is called when your extension is activated
// your extension is activated the very first time the command is executed
function activate(context) {

    // Use the console to output diagnostic information (console.log) and errors (console.error)
    // This line of code will only be executed once when your extension is activated
    console.log('Congratulations, your extension "commands-test" is now active!');

    var channel = vscode.window.createOutputChannel('Ext1');

    // The command has been defined in the package.json file
    // Now provide the implementation of the command with  registerCommand
    // The commandId parameter must match the command field in package.json
    var disposable = vscode.commands.registerCommand('extension.sayHello', function () {
        // The code you place here will be executed every time your command is executed

        let v = process.version;
        console.log(v);

        let buffer = new ArrayBuffer(320000);
        console.log('byte buffer', buffer.byteLength);

        let view = new Int32Array(buffer);
        console.log('int32 view', view.length);

        for (let i = 0; i < view.length; i++) {
            view[i] = i * Math.random();
        }

        console.log('made it...');

        let data = new Array(10001);
        data.fill(42);

        console.log(data.length);

        let longString = data.join('oooooo');
        longString += '<TOO LARGE>';

        console.log(longString);

        channel.appendLine(longString);

        // Display a message box to the user
        // return vscode.commands.executeCommand('vscode.openFolder', vscode.Uri.file('\\\\psf\\Home\\Code\\_samples\\ConsoleAppDnx'), true);
        // return vscode.commands.executeCommand('vscode.openFolder', vscode.Uri.file('\\\\psf\\Home\\Code\\_samples\\ConsoleAppDnx'), false);
    });

    context.subscriptions.push(disposable);
}
exports.activate = activate;

// this method is called when your extension is deactivated
function deactivate() {
}
exports.deactivate = deactivate;

[bpasero]

@isidorn @weinand fyi

[bpasero]

I can not reproduce on Mac, but on Windows. I can also not reproduce with a standalone node.js snippet with the same code using node.js 5.11.0.

[isidorn]

I tried on windows and if I use a smaller data array I can not reproduce. With a larger data array it reproduces seldomly.
As @bpasero noticed electron's node 5.1.0.0 and barebone node 5.1.0.0 are different in one aspect, first uses chromium 49 and the former 47. This might have an impact on debugging. We might as well update in may to a new electron version which should take care of this 'incompatibility'.
Due to the reasons above I propose to move this to May

I will also drill deeper tomorrow to check if there is something we can do, though since it is not reprodcuing constantly for me I am having a hard time doing that.

[isidorn]

I can nicely repro on my win vm with Joh's sample, but not on my real win machine.
There are two issues:

• Step jumps over too many lines -> our node debug simly gets the wrong stack trace when asking for the stack trace from node in this case
• Step instead of steps just continues -> our node debug adapter is not getting a 'break' event from node, so it never enters a stopped state.

So it seems to be an issue in node for both of these issues. It might be the different chromium versions used between electron and nodejs.

Not sure what we can do here, even though this makes the extension debugging experience worse it is seldomly happening and only on windows.

@egamma opinion welcome

[bpasero]

As soon as Electron is out with Chrome 50 support, V8 versions should be aligned again and we should re-test this.

[isidorn]

Ping @chrisdias to decide if we should mention this in release notes
Also forwaring this issue to @weinand

[chrisdias]

@isidorn I'm not sure it needs to be in the release notes as I don't think people will look there first to find the issue. People will hopefully be able to find the issue here and watch the progress.

[weinand]

This seems to work fine in the latest. Couldn't reproduce in Windows 10 VM.

[jrieken]

This still happens for me. Still, in the same weird way as before - not always but almost always.

[weinand]

@jrieken is this project living on a filesystem that is shared between OS X and Windows?

[jrieken]

No, local to the VM C:\Users\jrieken\Code\ddd\src\extension.ts

[weinand]

@jrieken does this problem occur if longstring is short, e.g. <= 80 ?

[jrieken]

sometimes this occurs already on the first console.log statement here

let v = process.version;
console.log(v);

[jrieken]

So I think it's unrelated to that.

[weinand]

@jrieken but it only occurs for 'console.log' (and it does not happen if you comment out the console.logs)?

If yes, then this could be a hint towards finding the culprit.

'console.log' in the extension is somewhat 'heavy' because it is read by the EH instance of VS Code, which sends it back to the original VS Code instance where the debugger runs. There it is broadcasted and the debugger picks it up to append it to the debug console.

[jrieken]

yes - only ever in console.log-statements

[weinand]

@jrieken you are seeing this when running Windows in a VM?

When reading all the other comments in this issue it seems that this problem only occurs when running in a VM, but not in real Windows. This supports the hypothesis that this problem is connected to the heavy 'console.log' flow which is more easily affected by a slow setup, e.g. a VM.

[jrieken]

yes - win10 VM

[weinand]

Probably related to nodejs/node#7219

[weinand]

must be fixed in node.js, see nodejs/node#7219