continuedev
[error] Error: Parsing failed
Before submitting your bug report
- [X] I believe this is a bug. I'll try to join the Continue Discord for questions
- [X] I'm not able to find an open issue that reports the same bug
- [X] I've seen the troubleshooting guide on the Continue Docs
Relevant environment info
- OS: Windows 11
- Continue: v0.9.182 (pre-release)
- IDE: vscode 1.91.0
- Model:
- config.json:
Description
// at _Parser.parse (c:\Users\jyomu\.vscode\extensions\continue.continue-0.9.182-win32-x64\out\extension.js:89096:81)
parse(e4, t4, r4) {
if ("string" == typeof e4)
currentParseCallback = (t5, r5, _4) => e4.slice(t5, _4);
else {
if ("function" != typeof e4)
throw new Error("Argument must be a string or a function");
currentParseCallback = e4;
}
this.logCallback ? (currentLogCallback = this.logCallback, C._ts_parser_enable_logger_wasm(this[0], 1)) : (currentLogCallback = null, C._ts_parser_enable_logger_wasm(this[0], 0));
let _3 = 0, s4 = 0;
if (r4 && r4.includedRanges) {
_3 = r4.includedRanges.length, s4 = C._calloc(_3, SIZE_OF_RANGE);
let e5 = s4;
for (let t5 = 0; t5 < _3; t5++)
marshalRange(e5, r4.includedRanges[t5]), e5 += SIZE_OF_RANGE;
}
const n2 = C._ts_parser_parse_wasm(this[0], this[1], t4 ? t4[0] : 0, s4, _3);
if (!n2)
throw currentParseCallback = null, currentLogCallback = null, new Error("Parsing failed");//:89096
const a2 = new Tree(INTERNAL, n2, this.language, currentParseCallback);
return currentParseCallback = null, currentLogCallback = null, a2;
}
// at _ImportDefinitionsService._getFileInfo (c:\Users\jyomu\.vscode\extensions\continue.continue-0.9.182-win32-x64\out\extension.js:90002:28)
async _getFileInfo(filepath) {
const parser = await getParserForFile(filepath);
if (!parser) {
return {
imports: {}
};
}
const ast = parser.parse(await this.ide.readFile(filepath), void 0, {//:90002
includedRanges: [
{
startIndex: 0,
endIndex: 1e4,
startPosition: { row: 0, column: 0 },
endPosition: { row: 100, column: 0 }
}
]
});
// at async PrecalculatedLruCache.initKey (c:\Users\jyomu\.vscode\extensions\continue.continue-0.9.182-win32-x64\out\extension.js:87952:25)
async initKey(key) {
const index2 = this.items.findIndex((item) => item[0] === key);
if (index2 < 0) {
const value = await this.calculateValue(key);//:87952
this.items.push([key, value]);
if (this.items.length > this.N) {
this.items.shift();
}
} else {
const [item] = this.items.splice(index2, 1);
this.items.push(item);
}
}
https://github.com/continuedev/continue/blob/ed37dcfb7ab98d7a70759991cbf4abe868beea89/core/util/LruCache.ts#L8-L25
To reproduce
No response
Log output
2024-07-14 11:21:07.632 [error] Error: Parsing failed
at _Parser.parse (c:\Users\*\.vscode\extensions\continue.continue-0.9.182-win32-x64\out\extension.js:89096:81)
at _ImportDefinitionsService._getFileInfo (c:\Users\*\.vscode\extensions\continue.continue-0.9.182-win32-x64\out\extension.js:90002:28)
at async PrecalculatedLruCache.initKey (c:\Users\*\.vscode\extensions\continue.continue-0.9.182-win32-x64\out\extension.js:87952:25)
@jyomu Does this error just silently appear in the logs, or does it have further effects? If you are able to share an example of a file that causes parsing to fail that would be very helpful in debugging
I encounter this error every time I click inside an editable block of any jupyter notebook (it logs twice). It does not seem to have any other effects.
- OS: Pop!_OS 22.04 LTS x86_64
- Continue: 0.8.43
- IDE: vscode 1.91.0
- Model: gpt-4o
- config.json
{
"models": [
{
"apiKey": "",
"completionOptions": {
"temperature": 0
},
"contextLength": 131072000,
"model": "gpt-4o",
"provider": "openai",
"systemMessage": "You are an AI language model that always uses LaTeX for mathematical expressions. Whenever you include equations or variables, ensure they are enclosed in $ signs. For example, f = wx + b should be written as $f = wx + b$ and \\mathbf{y} should be written as $\\mathbf{y}$. You give helpful and concise responses.",
"title": "GPT-4o"
}
],
}
@sestinj i have exactly the same problem. It even happens without an open file in a new window
Also it slows down opening new files by a lot from the explorer window. This is very noticeable if working over SSH.
2024-07-18 22:24:37.752 [error] Error: Parsing failed
at _Parser.parse (c:\Users\filip\.vscode\extensions\continue.continue-0.8.43-win32-x64\out\extension.js:94941:81)
at _ImportDefinitionsService._getFileInfo (c:\Users\filip\.vscode\extensions\continue.continue-0.8.43-win32-x64\out\extension.js:95847:28)
at async PrecalculatedLruCache.initKey (c:\Users\filip\.vscode\extensions\continue.continue-0.8.43-win32-x64\out\extension.js:93797:25)
I am facing this same issue, although the effects of it may be more severe for me. The connection between these uncaught exceptions being constantly spammed and the occurrence of this problem can only be speculative, but seemingly only when the Continue extension is enabled, the extension host will freeze after a few minutes (and ~ 22 errors) with "Extension host unresponsive", and almost all functionality of VSCode will not complete, including saving files, running tasks, and file operations in the file browser, requiring a reload.
(Switching to prerelease fixes the "Cannot read properties" error like this, this, or this, but not the other problems)
2024-07-19 00:21:50.837 [error] Error: Parsing failed
at _Parser.parse (/Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/extension.js:88850:81)
at _ImportDefinitionsService._getFileInfo (/Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/extension.js:89756:28)
at async PrecalculatedLruCache.initKey (/Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/extension.js:87706:25)
2024-07-19 00:21:55.009 [error] TypeError: Cannot read properties of undefined (reading 'apply')
at e4.<computed> (/Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/extension.js:88175:63)
at wasm://wasm/0055765a:wasm-function[15]:0x29b5
at wasm://wasm/000b54aa:wasm-function[234]:0x25635
at _Parser.parse (/Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/extension.js:88848:30)
at _ImportDefinitionsService._getFileInfo (/Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/extension.js:89756:28)
at async PrecalculatedLruCache.initKey (/Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/extension.js:87706:25)
Edit: Another detail: When this happens, the Code Helper (Plugin) running Continue begins to consume 100% of 1 CPU core until restart of VSCode
$ code --status
CPU % Mem MB PID Process
0 106 64998 code main
0 49 65006 gpu-process
0 16 65007 utility-network-service
0 164 65012 window [1] (distributed-minio.sh — nodeS3mounts)
0 33 65135 ptyHost
0 0 65144 /opt/homebrew/bin/bash --init-file /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
0 0 66529 /opt/homebrew/bin/bash --init-file /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
100 41 65136 extensionHost [1]
0 0 65477 /Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/node_modules/@esbuild/darwin-arm64/bin/esbuild --service=0.17.19 --ping
0 41 65137 shared-process
0 33 65138 fileWatcher [1]
0 66 66522 extensionHost [2]
0 8 66682 /Users/justin/.vscode/extensions/continue.continue-0.9.184-darwin-arm64/out/node_modules/@esbuild/darwin-arm64/bin/esbuild --service=0.17.19 --ping
0 41 66526 fileWatcher [2]
Edit # 2: It seems that Parser.parse is present in getAst() in core/autocomplete/ast.ts, and being called in core/autocomplete/constructPrompt.ts. Although I am unsure why this exception seems not to be handled by the try/catch, I think the likely solution to the freezing problem might be an outdated version of the web-tree-sitter Nodejs module. https://github.com/tree-sitter/tree-sitter-javascript/issues/322
@zenarcher007 - hopefully this is resolved in https://github.com/continuedev/continue/pull/1828
We will be shipping a new pre-release in the next day or two, so please circle back once you get that installed and let me know if it fixes things for you 👍
@Patrick-Erichsen Great 👍. I did not notice the packages.json in core. I have been putting this version through its paces a bit, observing that when web-tree-sitter is turned back to 0.21, freezes and parse errors occur, whereas I cannot get them to occur after the version bump. While it's still possible it could be sporadic, it usually would freeze within the first 2 minutes of significant use, and I have been testing it for longer.
Awesome, thank you for taking the time to test between the two versions. Sounds like it's at least fixing the issue on your local 👍
@Patrick-Erichsen I may have made an oversight, and I apologize for this. Your pull request switches web-tree-sitter from version 0.21.0 to 0.22.0. However, I have noticed on my system that when switching this between the two versions, multi-line completion stops working with the latter (although single-line completion still works). I also tried version 0.22.6, but it doesn't seem to make a difference. I thought something had seemed a little odd afterwards, and speculating that Continue was helping out lesser than usual, I thought it was important to correct this.
On the newer version of web-tree-sitter, Continue produces the following error upon first opening a file, which seems, via extension.js, to be associated with web-tree-sitter. I thought to find where this is thrown from in the code, although there is little documentation on how to start the breakpoint-debugger for Continue on the contributing page.
x.onmessage @ localProcessExtensionHost.ts:378
log.ts:439 ERR [Extension Host] Aborted(LinkError: WebAssembly.instantiate(): Import #6 module="env" function="emscripten_memcpy_big": function import requires a callable)
console.ts:137 [Extension Host] Aborted(LinkError: WebAssembly.instantiate(): Import #6 module="env" function="emscripten_memcpy_big": function import requires a callable)
y @ console.ts:137
$logExtensionHostMessage @ mainThreadConsole.ts:39
S @ rpcProtocol.ts:458
Q @ rpcProtocol.ts:443
M @ rpcProtocol.ts:373
L @ rpcProtocol.ts:299
(anonymous) @ rpcProtocol.ts:161
B @ event.ts:1211
fire @ event.ts:1242
fire @ ipc.net.ts:650
Especially if others experience this issue, I might suggest switching this back for now
Hey @zenarcher007 , good catch, we are indeed reverting back to 21 for now. Please keep us in the loop on your unresponsive issues though. We've made some other improvements to parsing in recent commits so hopeful that it will solve itself.
This issue hasn't been updated in 90 days and will be closed after an additional 10 days without activity. If it's still important, please leave a comment and share any new information that would help us address the issue.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue was closed because it wasn't updated for 10 days after being marked stale. If it's still important, please reopen + comment and we'll gladly take another look!