vscode-cmake-tools
vscode-cmake-tools copied to clipboard
Remote extension Host terminated unexpectedly when running "CMake:Configure"
VSCode Version:1.41.0 CMake Tools Version:1.2.3
Install CMake Tools on remote linux machine and open project using remote-ssh, when running "CMake:Configure" frist time, it's OK.But run this command again, the extension host terminated unexpectedly.
@bobbrow Hi Bob, do you know who is the owner of CMake Tools Project? It seems that many issues don't get replied.
Hi @Lennon925, we try to add tags or respond to issues within a day of being posted. However, right now it is the holiday season in the United States, so many people are on vacation (including myself). Please excuse our delay in responding right now.
Hi @Lennon925, we try to add tags or respond to issues within a day of being posted. However, right now it is the holiday season in the United States, so many people are on vacation (including myself). Please excuse our delay in responding right now.
Thanks for your reply and sorry about I forgot Christmas Day. Happy Christmas.
I clone CMake-Tools source code and found:
const new_db = await CompilationDatabase.fromFilePath(compdb_path);//514 line of src\cmake-tools.ts
const data = await fs.readFile(dbpath); // 69 line of src\compdb.ts
This line results in remote extension host crash when compile-command.json is large. (Currently I am using remote-ssh). After I commented out 514 line of src\cmake-tools.ts, this issue was solved.
In addition, how to debug extensions using remote-ssh when you develop remote extensions. It seems that extensions can't be actived on remote-ssh debug mode. I reported this issue on https://github.com/microsoft/vscode-remote-release/issues/1830
Hi @Lennon925 , thank you for your understanding with our slow reply over the holidays break. I was not on vacation, but indeed as @sean-mcmanus said (on issue https://github.com/microsoft/vscode-cpptools/issues/4768) I wasn't able to follow closely the issues and PRs on CMake-Tools due to other work items and assignments that took longer than expected.
Just by reading all the related reports I don't have a quick answer for you but I want to start reproducing the problem, try your experimental fix and some other ideas @sean-mcmanus is having. I need to do some debugging of the CMake Tools codebase (for which I'm pretty new) to gain the understanding needed for recommending a good approach for you in developing your extension or most likely for fixing our CMake Tools extension to support better your scenario.
Let me give you more info later on Monday next week.
Hi @Lennon925 , thank you for your understanding with our slow reply over the holidays break. I was not on vacation, but indeed as @sean-mcmanus said (on issue microsoft/vscode-cpptools#4768) I wasn't able to follow closely the issues and PRs on CMake-Tools due to other work items and assignments that took longer than expected.
Just by reading all the related reports I don't have a quick answer for you but I want to start reproducing the problem, try your experimental fix and some other ideas @sean-mcmanus is having. I need to do some debugging of the CMake Tools codebase (for which I'm pretty new) to gain the understanding needed for recommending a good approach for you in developing your extension or most likely for fixing our CMake Tools extension to support better your scenario.
Let me give you more info later on Monday next week.
Thank you very much!
So, just to confirm, the issue here is that it takes too long to parse the compile_commands.json
file?
Yeah, it could be the JSON.parse call (I didn't see that before, and "readFile" was mentioned so I just assumed that was the cause) -- changing it to use something asynchronous like JSONStream might work.
@Lennon925 Our C/C++ extension doesn't hit this issue because it parses compile_commands.json in our separate process and not TypeScript.
So, just to confirm, the issue here is that it takes too long to parse the
compile_commands.json
file?
Yes. It's fs.readFile. I tried to use stream to read file but it didn't work.
Yeah, it could be the JSON.parse call (I didn't see that before, and "readFile" was mentioned so I just assumed that was the cause) -- changing it to use something asynchronous like JSONStream might work.
@Lennon925 Our C/C++ extension doesn't hit this issue because it parses compile_commands.json in our separate process and not TypeScript.
I think you are right. this issue can be solved by parsing compile-command.json in a separate process like language server process.
Hi @Lennon925 , thank you for your understanding with our slow reply over the holidays break. I was not on vacation, but indeed as @sean-mcmanus said (on issue microsoft/vscode-cpptools#4768) I wasn't able to follow closely the issues and PRs on CMake-Tools due to other work items and assignments that took longer than expected.
Just by reading all the related reports I don't have a quick answer for you but I want to start reproducing the problem, try your experimental fix and some other ideas @sean-mcmanus is having. I need to do some debugging of the CMake Tools codebase (for which I'm pretty new) to gain the understanding needed for recommending a good approach for you in developing your extension or most likely for fixing our CMake Tools extension to support better your scenario.
Let me give you more info later on Monday next week.
Any update?
I actually ended up taking some unexpected out of office time, back in office now and looking at this today.
Hi @Lennon925 , would you be able to share with us a repro project? Thanks.
CHANGE NODE_OPTIONS WORKS FOR ME https://github.com/microsoft/vscode-cmake-tools/issues/2586
@Lennon925 Could you confirm if this issue is still occurring? Thanks!
This issue is now marked as 'stale' due to there being no activity on it for the past 30 days and being labelled 'more info needed'. Unless the 'stale' label is removed or the issue is commented on, this will be closed in 7 days. If you would like to make this issue exempt from getting stale, please remove the 'more info needed' and 'stale' labels or add the 'stale-exempt' label
This issue is now closed due to there being no activity on it for the past 7 days since being marked as 'stale'.