Change:
"vscode-oniguruma": "1.7.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "9.0.0", <del> "xterm": "5.3.0-beta.39", </del> <ins> "xterm": "5.3.0-beta.42", </ins> "xterm-addon-canvas": "0.5.0-beta.9", <del> "xterm-addon-image": "0.6.0-beta.1", "xterm-addon-search": "0.13.0-beta.7", "xterm-addon-serialize": "0.11.0-beta.7", </del> <ins> "xterm-addon-image": "0.6.0-beta.2", "xterm-addon-search": "0.13.0-beta.8", "xterm-addon-serialize": "0.11.0-beta.8", </ins> "xterm-addon-unicode11": "0.5.0", <del> "xterm-addon-webgl": "0.16.0-beta.13", "xterm-headless": "5.3.0-beta.39", </del> <ins> "xterm-addon-webgl": "0.16.0-beta.14", "xterm-headless": "5.3.0-beta.42", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

Discussion:
Type: <bBug</bGPU Acceleration for terminals to "off" in settings a terminal the terminal the left terminal (the right terminal doesn't seem to have this issue) crashes VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-04T05:35:09.023Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ systemd-unit-file1.0.6 codespaces1.14.14 jupyter-keymap1.1.2 remote-containers0.305.0 remote-wsl0.81.0 nagios1.1.0 vim1.25.2 vscode-language-jsonata0.4.0 vscode-eslint2.4.2 gitlens14.2.0 prettier-vscode10.1.0 python2023.14.0 vscode-pylance2023.8.10 matchit2.0.1 ansible2.6.92 vscode-yaml1.14.0 jinjahtml0.20.0 svant-all-autocomplete0.0.6 svant-vscode-fzf0.0.3 </details<!-- generated by issue reporter --
Repros on Windows sometimes when killing a terminal: ! Assigning for help since we shouldn't be able to crash from the browser so this must be a Chromium/Electron/node-pty bug. Probably related to the new Electron update?
Crash dump:
Following findings are from the runtime side, <details<summaryStacktrace</summary</details1) Crash is triggered when triggers a layout via property from and when resolving the css rules for element 2) The stack trace was obtained from a DCHECK build which shows that was attempting to work with a invalid ruleset in 3) From the repro case I thought this happened when the active style sheets were not updated when the left terminal was destroyed after the layout was triggered similar to , but the stack shows that there is call to which actually signals . 4) Looking at class, is a strong and given the contents object has not been garbage collected then it could only mean that there was a call to without a matching before the loop was started.

5) I thought creating a minimal repro would shed more light, but interestingly the same steps do not crash when running in codespaces terminal on both Chromium 114 and Chromium 115 browsers. However, the crash still happens when running VSCode desktop with Electron nightly based on Chromium 117. So at this point, it is either that a patch in Electron is messing with the style engine or codespaces terminal behaves differently from the desktop terminal in terms of layout. I was able to confirm there are no patches to the style engine in Electron. 6) I have the following fix to which avoids using invalid rulesets and it confirms to avoid the crash. 7) I would need to create a minimal repro outside VSCode desktop using so that we can revive which was closed due to lack of repro. I am not familiar with how terminals are setup on VSCode side, will work with to create the repro case for browsers.
I tried to bisect the runtime changes and surprisingly found that issue repros even when using Electron 22 shipped in our with main branch, so hinted to a problematic bump. Bisect in vscode revealed it to be change and further bisecting in points to Particularly, the following destruction calls of when the screen element is destroyed messes up the loop in . I think we should be able to create a minimal repro with this context.
There are two workarounds until the crash is resolved, either use the since CSP issue is not a problem for VSCode desktop or move to a shadow DOM, that way the style sheets can be hosted on which will then automatically get disposed when the terminal element is destroyed. I feel fallback is the easier workaround of the two, will leave it to you
Upstream issue filed at
The crash is worked around when we update to bring in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!