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

[Linux] Extension host crashes when using 1.20.3 #49

Open
axel-lebourhis opened this issue May 15, 2023 · 9 comments
Open

[Linux] Extension host crashes when using 1.20.3 #49

axel-lebourhis opened this issue May 15, 2023 · 9 comments
Labels
bug Something isn't working

Comments

@axel-lebourhis
Copy link

Hi !

When I use the iar extension on latest version, the Extension Host crashes when loading the extension.
I don't have the issue on 1.20.2 so far, and I'm running ubuntu 20.04.

Following is the log from the Extension Host output:

2023-05-12 09:19:04.307 [info] ExtensionService#_doActivateExtension iarsystems.iar-build, startup: true, activationEvent: 'workspaceContains:**/*.ewp'
2023-05-12 09:19:05.445 [error] Error: View is not attached yet
	at new l (/home/nxf49031/.vscode/extensions/iarsystems.iar-build-1.20.3/out/src/extension/main.js:2:908992)
	at t.activate (/home/nxf49031/.vscode/extensions/iarsystems.iar-build-1.20.3/out/src/extension/main.js:2:881536)
	at kn.eb (/usr/share/code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:112:14705)
	at kn.db (/usr/share/code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:112:14409)
	at /usr/share/code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:112:12432
	at async v.n (/usr/share/code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:96:6644)
	at async v.m (/usr/share/code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:96:6607)
	at async v.l (/usr/share/code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:96:6064)
@HampusAdolfsson
Copy link
Collaborator

Hi!

The error in the log is completely harmless, so there is probably something else going wrong. What other symptoms are you seeing besides this error? Is there anything interesting in the logs for this extension (you can find them under "IAR Build" in the output panel)?

@axel-lebourhis
Copy link
Author

axel-lebourhis commented May 15, 2023

Hi Hampus,

I don't have any other logs as the IAR build extension doesn't even start, it doesn't appear in the output window.
The symptom is that the extension host crashes 3 times before suggesting to enable the bissect mode to identify the faulty extension causing those crashes.
The bissect doesn't help much, but by manually disabling the IAR extension, or reverting to 1.20.2, I don't reproduce the problem.
Note that my workspace contains a quite large number of .ewp files, I don't know if that can help.

EDIT: After restarting several time the extension host, it will work at some point, but this is not very stable behavior.

@HampusAdolfsson
Copy link
Collaborator

HampusAdolfsson commented May 15, 2023

I see, thanks!

The major change in 1.20.3 is that the extension queries all projects in the workspace for some intellisense information immediately when the extension starts. Unfortunately this seems to have quite a large performance impact in some cases, and is probably what is crashing the extension host.

The next version of the extension will support loading embedded workbench workspaces (.eww files), which should mitigate the problem. Then, the extension will only load intellisense information for the projects listed in the .eww file, not for every single project in the VS Code workspace. We can also see if there is some way to reduce the load on VS Code.

For now you can limit the number of projects opened by the extension by either using the "Projects to exclude" setting or VS Code's "Files: Exclude" setting. This is described in #41.

Do you know roughly how many .ewp files are in your workspace? It would be good for us to have an idea of where the limit is.

@HampusAdolfsson HampusAdolfsson added the bug Something isn't working label May 15, 2023
@axel-lebourhis
Copy link
Author

I have more than 230 .ewp files in my workspace.
Relying on the .eww seems like a good idea indeed, look forward to it :)
Do you mean that currently even if my selected project doesn't have an include path or a preprocessor flag, if another project has it, VS Code will consider it exists ? It would be quite unreliable, no ?

@HampusAdolfsson
Copy link
Collaborator

Include paths and preprocessor macros are configured on a per-file basis; when you open a file, only the project it belongs to is used to configure intellisense. The reason we query all projects for intellisense data is so that we are able to configure intellisense for files that do not belong to the active project.

@axel-lebourhis
Copy link
Author

Ok thanks for clarifying !

@HampusAdolfsson
Copy link
Collaborator

I've tried to reproduce this, but even with ~1000 projects things work fine for me. In any case, we have now released the .eww file support I mentioned earlier, please let me know if that solves the problem for you!

@JanWielgus
Copy link

@HampusAdolfsson That solved the problem for me (I have opened a similar issue that is closed now - issue #48).

@axel-lebourhis
Copy link
Author

Hi @HampusAdolfsson
I tried the new version, I can't reproduce the issue so far, so looks good ! I will let you know if I encounter the issue again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants