Vscode: Debug error > "No call stack available (Internal error: TypeError: Cannot read property '0' of undefined)."
- VSCode Version: Version 1.2.1 (1.2.1)
- OS Version: OS X El Capitan Version 10.11.4
Steps to Reproduce:
- Add a breakpoint
- Launch debug; it sometimes break 'somewhere' yet I don't have the control and the only message I receive is "No call stack available (Internal error: TypeError: Cannot read property '0' of undefined)."
See screenshot attached.
Sometimes it works, some other it does, on the same code
bgbahoue
All 63 comments
I have having the same exact issue.
- OS Version: OS X El Capitan Version 10.11.5
- VSCode Version: Version 1.2.0 (1.2.0)
alechirsch
on 15 Jun 2016
+1
maorhayoun
on 19 Jun 2016
+1
a624535537
on 30 Jun 2016
+1
icezohu
on 30 Jun 2016
What version of node are you using?
weinand
on 30 Jun 2016
It is 5.10.0, while vscode version is 1.2.1.
icezohu
on 30 Jun 2016
Since I'm not sure where this comes from (and I cannot reproduce it myself), I've added additional information to the error message and added some additional checks in the injected code. This will be in the June release (and tomorrow's Insider).
weinand
on 30 Jun 2016
I’m at v6.2.0
De : Andre Weinand [email protected]
RĂ©pondre Ă : Microsoft/vscode [email protected]
Date : jeudi 30 juin 2016 21:19
Ă€ : Microsoft/vscode [email protected]
Cc : Boris Gbahoué [email protected], Author [email protected]
Objet : Re: [Microsoft/vscode] Debug error > "No call stack available (Internal error: TypeError: Cannot read property '0' of undefined)." (#7683)
Since I'm not sure where this comes from (and I cannot reproduce it myself), I've added additional information to the error message and added some additional checks in the injected code. This will be in the June release (and tomorrow's Insider).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
bgbahoue
on 30 Jun 2016
I'm using VSCode v. 1.4.0-insider (updated right now) on Windows 10 and I have the same problem (tested with node 6.2.2 and node 6.3).
Error message: 'No call stack available ({_command}: Internal error: TypeError: Cannot read property '0' of undefined).
The error is very common, and is almost impossible debug anything :(
sarvaje
on 8 Jul 2016
@sarvaje does the problem occur in VS Code 1.3 too?
Please add steps and code for how to reproduce this.
weinand
on 8 Jul 2016
yes, the problem is happening for a long time.
Maybe is not related, but I notice that the problem ocurror more ofen when I try to debug promises (using bluebird for example)
sarvaje
on 8 Jul 2016
+1 Had that problem today for the first time debugging a command line node app with Q based promises. OS/X current, Node 6.2.2, Code 1.3.1 (2016-07-12)
Stwissel
on 14 Jul 2016
@Stwissel do you have a small reproducible case that you can share?
weinand
on 14 Jul 2016
Since I could not reproduce this problem, I've instrumented node-debug so that we can get additional information when the problem occurs.
In the July release (and next Monday's insider release) VS Code should show an almost complete call stack even is this problem occurs.
Only stackframes that run into the problem will show an error in angle brackets.
If you are affected by this problem please add the following property to your launch configuration:
"trace": "all"
If the problem occurs again, a stacktrace will appear on the debug console.
Please add this information here so that I can investigate.
weinand
on 16 Jul 2016
@weinand : depends what is considered "small" :-)
I have a small program that extracts the "url" value from har files (the JSON you get when you record a browser session. I'm sure you can find some of those. The project is a single js file.
package.json
{
"name": "harparser",
"version": "0.0.1",
"description": "Parse har files to get specific information out",
"main": "app.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"har",
"browser",
"api"
],
"author": "Stephan H. Wissel",
"dependencies": {
"lodash": "^4.13.1",
"q": "^1.4.1",
"querystring": "^0.2.0",
"stream-json": "^0.4.2",
"url": "^0.11.0"
}
}
app.js
'use strict';
var sourceDir = '../rawHAR/';
var Combo = require('stream-json/Combo');
var Emitter = require('stream-json/Emitter');
var _ = require('lodash');
var Q = require('q');
var url = require('url');
var querystring = require('querystring');
var options = {
packKeys: true,
packStrings: true,
packNumbers: true
};
var fs = require('fs');
var objectCounter = 0;
var getCount = 0;
var postCount = 0;
var urlCollection = [];
var parameterCollection = [];
var doneCounter = 0;
console.log('Start App2');
var processingArray = [];
fs.readdir(sourceDir, function (err, data) {
data.forEach(function (element, counter, reference) {
var last = (counter === reference.length - 1);
console.log('Processing ' + sourceDir + element + (last ? ' (the last)' : ''));
if (element.indexOf('.har') > 0) {
// Add one to the list to be processes
doneCounter++;
processingArray.push(processOneFile(sourceDir + element));
}
});
console.log('Files are away, results coming in...');
Q.allSettled(processingArray).then(function (results) {
var alltheURLs = _.uniq(urlCollection);
var allTheParams = _.uniq(parameterCollection);
console.log('Found ', objectCounter, ' objects.');
console.log('API URLs with GET:' + getCount);
console.log('API URLs with POST:' + postCount);
console.log('Unique URLs: ' + alltheURLs.length);
console.log('Unique params: ' + allTheParams.length);
console.log(JSON.stringify(alltheURLs));
console.log(JSON.stringify(allTheParams));
// TODO write URLs into file
});
});
//processOneFile(sourceFile);
function processOneFile(fName) {
var deferred = Q.defer();
var combo = new Combo(options);
var emitter = new Emitter();
var method = 'unknown';
var attention = false;
var methodComing = false;
var pipeline = fs.createReadStream(fName).pipe(combo).pipe(emitter);
combo.on('data', function (chunk) {
++objectCounter;
});
pipeline.on('keyValue', function (key) {
methodComing = (key === 'method');
attention = (key === 'url');
});
pipeline.on('stringValue', function (stringValue) {
if (methodComing) {
method = stringValue;
}
if (attention) {
if (method == 'GET') {
getCount++;
}
if (method == 'POST') {
postCount++;
}
// Capture the URL
updateURLCollection(stringValue);
}
attention = false;
});
pipeline.on('finish', function () {
doneCounter--;
console.log('Finished ' + fName + ' (' + doneCounter + ')');
deferred.resolve(fName);
});
return deferred.promise;
}
// Rip the queries apart
function updateURLCollection(rawURL) {
var sourceURL = url.parse(rawURL);
// Capture the base URL
urlCollection.push(sourceURL.host + sourceURL.pathname);
// now process the parameters
var rawQuery = sourceURL.query;
if (rawQuery) {
var query = querystring.parse(rawQuery);
for (var param in query) {
parameterCollection.push(param);
}
}
}
That one shows the error. To test it, you need some har files in the ../rawHAR/ directory.
Stwissel
on 18 Jul 2016
@Stwissel thanks a lot for the code.
Here is what I did to try to reproduce the issue:
- with your files I've created project with VS Code 1.3.1, node 6.2.2 on OS X 10.11.5
- ran
npm install - created 120 *.har files, each about 2.5 MB
- set breakpoints in the three
pipeline.oncallbacks (lines: 73, 78, 96) - started debugging and stepped through the code by keeping either F5, F10, or F11 continuously pressed.
- did this about 10 times without running into the issue.
Did you do anything differently when you saw the problem?
weinand
on 18 Jul 2016
On VS Code 1.3.1 and node v. 5.9.1 I have this problem only when trying to debug mocha tests with the following launch configuration
{
"name": "Run mocha",
"type": "node",
"request": "launch",
"program": "${workspaceRoot}/node_modules/mocha/bin/_mocha",
"stopOnEntry": true,
"args": [ "--no-timeouts", "--colors", "test/**/*.test.js"],
"cwd": "${workspaceRoot}",
"runtimeExecutable": null,
"env": { "NODE_ENV": "testing"}
}
It stops on entry but on following breakpoints I get the problem mentioned above.
Debugging node running regularly produces no errors.
jgsacris
on 22 Jul 2016
I wish I could give you guys something more concrete to deal with, but I've found that this issue most often crops up with long running processes. I have a webserver which runs for a long time in vscode. In the first few minutes, I can almost always consistently break on a breakpoint.
After 10-20 minutes of runtime, more often than not, I run into this issue when trying to debug.
johnfn
on 26 Jul 2016
FWIW, I'm getting almost the same error exept that it says vscode_backtrace: Internal Error, instead of just Internal Error.
My versions are:
OSX El Capitan 10.11.5
VS Code 1.4.0 6276dcb0ae497766056b4c09ea75be1d76a8b679
Node 6.2.2
juancampa
on 6 Aug 2016
@juancampa in what situations are you seeing his error? Can you share the project where you experience the problem?
weinand
on 6 Aug 2016
This bug is pretty bad and breaks debugging in a high percentage of cases for me. I can reproduce it consistently; let me know if there's any way I can help you guys track it down.
johnfn
on 20 Aug 2016
@johnfn it would be great if you could share some code and a project setup where you experience the problem. If we can reproduce the problem, we can investigate and probably fix.
But so far we could not reproduce...
weinand
on 20 Aug 2016
Ahh, that's unfortunate. It's my workplace code, so I can't really share it, and it's rather large (100k loc).
Is there any other assistance I could give?
My guess is it probably has something to do with deep callstacks, or generators & promises (which we use a lot of).
johnfn
on 20 Aug 2016
@johnfn use of promises seems to be a common pattern of this issue. What kind of promises are you using?
weinand
on 22 Aug 2016
Hi @weinand yes it happens while using co with generator functions. Now it happens every time I debug generator code blocks.
icezohu
on 22 Aug 2016
@icezohu what is "co" ?
weinand
on 22 Aug 2016
It's an npm module which could help make the generator code blocks elegant.
https://github.com/tj/co
@weinand
icezohu
on 22 Aug 2016
Lots of Bluebird.coroutine, which transforms generators into a sort of async/await pattern. Bluebird is a Promise library for js.
(interesting, yes, it's exactly the same as co.)
johnfn
on 22 Aug 2016
'no call stack available' appeared again this morning in release:
Version 1.5.0-insider (1.5.0-insider)
5fb5131a7d8ab0245af3653fca77f31d7d81d735
2016-09-02T15:32:08.421Z
heavy async context and a breakpoint on gives the 'no call stack available' error, breakpoint off it continues without the 'no call stack available' .
pietgk
on 3 Sep 2016
Oh, oh, I have an easily reproducible testcase. At least on my setup (macOS Sierra beta, VSC 1.5.2).
- Clone https://github.com/Zarel/flodoc
- Checkout 3d6332eea4
- Set
launch.jsonto
{
"version": "0.2.0",
"configurations": [
{
"name": "Run mocha",
"type": "node",
"program": "${workspaceRoot}/node_modules/mocha/bin/_mocha",
"stopOnEntry": false,
"args": ["test/spec/*"],
"cwd": "${workspaceRoot}",
"runtimeExecutable": null,
"env": { "NODE_ENV": "development"}
}
]
}
- Set a breakpoint on line 73 of
src/converter.js - Debug "Run mocha"
- Mash "Continue" a few times 7.
Zarel
on 15 Sep 2016
+1 with the problem.
OSX 10.11.6
Visual Studo Code - Version 1.5.3 (1.5.3)
In my case it seems related to bluebird Promise. I removed bluebird from the file I was debugging, using the standard ES6 Promise instead, the error stopped and I was able to debug it.
pisrael
on 27 Sep 2016
I've run into it without using Bluebird, but it's significantly more rare.
johnfn
on 2 Oct 2016
I can also confirm this issue is happening inside a generator function using bluebird's co
dsbert
on 25 Oct 2016
If you can use node >= v6.3 then please try our new experimental debugger by setting the type attribute in your launch config to "node2". That should solve the issue.
weinand
on 25 Oct 2016
Adding "trace": "7683" to the launch config did not change anything for me and I still got the same error. Using node2 seems to have fixed it! đź‘Ť
ssynix
on 25 Oct 2016
@ssynix glad to hear that node2 has fixed this for you.
setting 'trace' to the number of this issue does not make sense ;-)
A better value is "all".
weinand
on 25 Oct 2016
@weinand I was following your suggestion from earlier on this thread. VSCode 1.6.1 complains about it: Property trace is not allowed.
Either way, thanks for the suggestion!
ssynix
on 25 Oct 2016
@ssynix oops, I see. Sorry about the bogus trace value from above. I've fixed my comment.
weinand
on 25 Oct 2016
Thank you! @weinand
This was the most annoying issue ever.
CharlieScarver
on 3 Nov 2016
I still habe this issue with an attached debugging session. With "type":"node2" it won't attach and "trace": "all" does nothing. VSCode 1.7.2, macOS Sierra 10.12.1
cmdrsabre
on 30 Nov 2016
@cmdrsabre the "trace" option is not supported by node2. If you are using "attach" with node2, you'll have to make sure that node was started with the --inspect flag because only that enables the CDP debug protocol that node2 relies on.
@roblourens we should align the names of the tracing/logging options and make them official, so that they appear in intellisense ("trace" is not documented and we can drop it easily).
@roblourens if node2 cannot attach to a target you could add a hint to the timeout error: "Make sure that node was started with the '--inspect' flag".
weinand
on 30 Nov 2016
@weinand "node2" is not attaching (not used trace)
Cannot connect to runtime process, timeout after 10000 ms - (reason: Cannot connect to the target: Parse Error).
I'm running a jasmine testsuite inside a docker. Breakpoints in the specs work, but not in the application code (other thread), but I think it's more related to the massiv usage of promises.
cmdrsabre
on 30 Nov 2016
@cmdrsabre make sure that node is launched with the new "--inspect" flag. If it is not, node2 will not be able to attach to it successfully and will timeout with the error you are seeing.
weinand
on 30 Nov 2016
@weinand finally this worked. "node2" worked. Thanks a lot
cmdrsabre
on 30 Nov 2016
Same issue here with last vscode version.
Trying with node2 and get the following Unhandled error in debug adapter message :
******** Unhandled error in debug adapter - Unhandled promise rejection: TypeError: Column must be greater than or equal to 0, got -1
at SourceMapConsumer_findMapping [as _findMapping] (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/source-map/lib/source-map-consumer.js:543:13)
at SourceMapConsumer_generatedPositionFor [as generatedPositionFor] (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/source-map/lib/source-map-consumer.js:748:22)
at SourceMap.generatedPositionFor (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/vscode-chrome-debug-core/out/src/sourceMaps/sourceMap.js:159:34)
at SourceMaps.mapToGenerated (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/vscode-chrome-debug-core/out/src/sourceMaps/sourceMaps.js:28:18)
at args.breakpoints.forEach.bp (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/vscode-chrome-debug-core/out/src/transformers/baseSourceMapTransformer.js:63:53)
at Array.forEach (native)
at EagerSourceMapTransformer.setBreakpoints (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/vscode-chrome-debug-core/out/src/transformers/baseSourceMapTransformer.js:61:34)
at validateBreakpointsPat[...]
What's this?
rdewolff
on 22 Dec 2016
@rdewolff Can you open a new issue for that? That's a new issue and I'd like to look into it when I have time.
roblourens
on 22 Dec 2016
Also it would be very helpful if you run with "diagnosticLogging": true, then include the full log file from the path printed at the top of the console.
roblourens
on 22 Dec 2016
Any updates on this?
I am using runInContext from the VM module.
node2 plugin uses node-inspector, which cant debug code running under vm module at all, so I must use the regular node debugger in vscode. In my workspace its crashing all the time (runInContext and BlueBird project). What can I do?
Thanks
smulikHakipod
on 15 Jan 2017
Just updated vstudio and ran into this problem
Version 1.9.0
Commit 27240e71ef390bf2d66307e677c2a333cebf75af
Date 2017-02-02T08:31:00.827Z
Shell 1.4.6
Renderer 53.0.2785.143
Node 6.5.0
geogeim
on 6 Feb 2017
If you can use node >= v6.3 then please try our new experimental debugger by setting the type attribute in your launch config to "node2". That should solve the issue.
weinand
on 6 Feb 2017
was running into this with node 6.9.5 and vscode Version 1.9.1 (1.9.1)
changed launch config to node2 works
anyone else be sure to STOP the debug process and start fresh, rather than "retry"
ilovett
on 23 Feb 2017
I am also experiencing this error. The problem persists across reinstallation of VSCode, updating VSCode, node, and electron, and clearing /Library/Application Support/Code
Current environment:
VSCode 1.10.1
Mac OSX 10.11.6
node v7.6.0
electron v1.6.1
I am not able to use "node2"; the debugger will not attach, even though electron is being called with --inspect. Issue 19681 suggests that "node2" simply will not work with electron.
I've noticed that every time I restart my computer, the debugger will hit the breakpoint normally (ie returning a valid callstack and variable information) once and only once. After that, it reverts to the error state and nothing I do fixes it.
It seems like some cached file is in an invalid state. Does vscode have some cache I can clear?
Edit: I found the cached data in /Library/Application Support. Clearing it doesn't fix the issue.
Edit2: I also tried building VSCode from source. Same issue.
Edit3: Downgrading to electron 1.5.x fixes this for me after all.
bgradin
on 6 Mar 2017
Same with VSCode 1.10.1. (Node 6.9.4)
In my situation it looks like this:
- I set 3 breakpoints and start new debug session. Debugger correctly stops on all three breakpoints.
- I repeat previous action in the same debug session. Debugger stops on first and second breakpoint. But for third breakpoint it stops on unknown location and I get error "No call stack available (Internal error: TypeError: Cannot read property '0' of undefined)."
- if I restart debug session it works again for the first time, but not for second, third etc..
The situation is the same for legacy and inspector protocol.
For me breakpoints are practically unusable, because after getting error for the first time, they become totally unreliable.
edvinv
on 7 Mar 2017
I'm hitting the same thing on 1.10.2, can we re-open this issue?
chiangf
on 4 Apr 2017
Sounds like the new 'inspector protocol' debug adapter fixed this for everyone. I recommend using "protocol": "inspector" in your node launch config, if you are using Node v6.9+
roblourens
on 4 Apr 2017
@chiangf alternatively you could try "protocol": "legacy" with the Insiders build (1.11.0). We've fixed an issue in March that might have solved this issue as well.
weinand
on 4 Apr 2017
I'm having the same issue as @bgradin with electron. Unfortunately you cannot use node2 with electron so I have to downgrade electron to 1.5.x to get it to work. Not sure if this is related to electron or vscode.
brtthomp
on 4 Apr 2017
@brtthomp have you tried to use the Insiders release?
weinand
on 4 Apr 2017
@weinand That seems to have fixed the issue even with electron 1.6.x+. I didn't read the comments well enough to realize the Insiders build had a potential fix in it. Thanks!
brtthomp
on 5 Apr 2017
@brtthomp thanks for trying again.
The March stable release will appear soon...
weinand
on 5 Apr 2017
still happening as of now
VSCode: Version 1.11.2
Node: Version v7.7.2
this didn't happen to me before I updated.
jlira2
on 15 Apr 2017
@jlira2 please add "protocol":"inspector" to your launch config. This should make the problem disappear.
weinand
on 15 Apr 2017
Just ran into the same problem, however in my case it was some issue within node module ([email protected]) that caused the issue. Downgrading lodash has solved the issue for me.
michaelkuk
on 24 Apr 2017
Related issues
villiv
·
3Comments
trstringer
·
3Comments
sirius1024
·
3Comments
sijad
·
3Comments
philipgiuliani
·
3Comments
Most helpful comment
If you can use node >= v6.3 then please try our new experimental debugger by setting the
typeattribute in your launch config to "node2". That should solve the issue.