Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Callstack shows "VMundefined" when debugging typescript with legacy protocol #27769

Closed
roblourens opened this issue May 31, 2017 · 5 comments
Closed
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug debug Debug viewlet, configurations, breakpoints, adapter issues verified Verification succeeded
Milestone

Comments

@roblourens
Copy link
Member

roblourens commented May 31, 2017

#26557

may-31-2017 11-20-16

I step, then it shows VMundefined for frames after the first one for a second, then resolves to the correct details.

Node 7.8

@roblourens roblourens added the debug Debug viewlet, configurations, breakpoints, adapter issues label May 31, 2017
@weinand weinand assigned isidorn and unassigned weinand May 31, 2017
@weinand
Copy link
Contributor

weinand commented May 31, 2017

@roblourens I cannot reproduce this when using the node-debug project (or some other smaller samples). Could you make your test program available?

@isidorn any idea why the DA is even called for the frames after the top frame?

@roblourens
Copy link
Member Author

I'm debugging the TypeScript compiler with a breakpoint at tsc.ts:149. Sorry that's what I meant by "debugging typescript" :)

@isidorn
Copy link
Contributor

isidorn commented Jun 1, 2017

Probably a timing issue I can also see it. Here are exact steps

Steps to Reproduce:

  1. git clone https://github.com/Microsoft/TypeScript.git
  2. npm install, npm install jake
  3. jake local
  4. set breakpoint in tsc.ts:149
  5. Use the following launch.json
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "node",
            "request": "launch",
            "program": "${workspaceRoot}/src/compiler/tsc.ts",
            "stopOnEntry": false,
            "args": ["PATH TO ANY TS FILE"],
            "cwd": "${workspaceRoot}",
            "preLaunchTask": null,
            "runtimeExecutable": null,
            "runtimeArgs": [
                "--nolazy"
            ],
            "env": {
                "NODE_ENV": "development"
            },
            "externalConsole": false,
            "sourceMaps": true,
            "outDir": "${workspaceRoot}/built/local"
        }
    ]
}

@isidorn isidorn assigned weinand and unassigned isidorn Jun 1, 2017
@weinand
Copy link
Contributor

weinand commented Jun 1, 2017

To improve stepping performance VS Code has started to get the stacktrace in two chunks: the first frame immediately in response to the stopped event. And after some delay the rest of the frames and the variables for the first frame.

If the number of variables and frames is large, the node.js backend is swamped by the variable request and fails on returning valid stackframes. This results in the "VMundefined" stackframes.

The fix is to better protect against the failing backtrace request and let the stackTrace request fail instead of returning bogus stackframes.

@weinand weinand added this to the May 2017 milestone Jun 1, 2017
@weinand weinand added the bug Issue identified by VS Code Team member as probable bug label Jun 1, 2017
@dbaeumer
Copy link
Member

dbaeumer commented Jun 2, 2017

Verfied using the steps from #27769 (comment)

@dbaeumer dbaeumer added the verified Verification succeeded label Jun 2, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug debug Debug viewlet, configurations, breakpoints, adapter issues verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

4 participants