-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
[Meta] Crash with webview after updated to 1.43.0 #92420
Comments
(Experimental duplicate detection) |
I too am experiencing random crashes while using VSCode 1.43. Since upgrading, VSCode seems to crash at random. I have been unable to replicate the exact steps but I do find it crashes more often when I navigate the application using the keyboard (instead of using the mouse). This may be a false lead but I believe it is worth noting. I disabled all installed extensions and used VSCode as normally as I could but the random crashing persisted. I have attached my raw crash log from OSX Please let me know if you need any other information. |
Also experienced repeated crashes on my Mac right after the upgrade. At some point, after a crash, VSCode failed to start altogether — so I downgraded to 1.42.1. |
Same here, random non-reproducable crashes while using or while in background. Only started after the 1.43 update |
Well experiencing the same after upgrading to version 1.43.0 on my mac. |
Can everyone try adding this setting and see if the crash still happens Also can you provide the info based on #92192 (comment) |
I'm having similar issues, but in my case it seems to crash after switching between windows roughly every 15 mins. This only start happening today. I have not added any new extensions in weeks, and I did attempt disabling all of them, but VsCode still crashed Here's 15 logs related to this, not all are the same. Here's the most common one. |
I've been trying this for about an hour and It looks promising. No crashes yet. |
Thanks @lopezhansel for the crash reports, they indicate the same trace as #92192 (comment) and based on your last comment it confirms crash originates from electron webview. To further narrow down a reliable repro, would be good to know what kind tabs are opened when you see the crash, for ex: is there any kind of markdown editor ? /cc @mjbvz what other actions would trigger an electron webview creation ? |
Ooh; I use the VsCoq plugin, which I guess uses a webview for the "proof state" (https://github.com/coq-community/vscoq/blob/f587c15aaa3d3adef3c2e87f429328b2d1906942/client/src/HtmlCoqView.ts#L119). |
@deepak1556 We should only create electron webviews in two cases:
Webviews are used in VS code for the following features:
|
I was definitely editing JavaScript, and might have been editing markdown at some point. It was a node.js application and I did edit and previewed a markdown file at one point. |
Can everyone try the latest insiders https://code.visualstudio.com/insiders/ and see if it still crashes ? If the setting |
To verify this crash due to race:
Demo -> https://streamable.com/zjavi |
There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
…3342) There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
…3374) There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420 Co-authored-by: deepak1556 <hop2deep@gmail.com>
…3342) There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
…3342) There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
…3342) (#23398) There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
…3342) (#23397) There are use cases of webview where the container holding the webview is not actually destroyed first, instead just webview gets removed from DOM, in such situations the browser process map is not updated accordingly and holds reference to stale guest contents, and any window operations like scroll, resize or keyboard events that has to chain through browser embedder will lead to UAF crash. Ref: microsoft/vscode#92420
Issue Type: Bug
Actual:
Instead of restart editor, it just stops.
Reproduce steps:
It's random, cannot reproduce.
VS Code version: Code 1.43.0 (78a4c91, 2020-03-09T19:34:44.548Z)
OS version: Darwin x64 19.3.0
System Info
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled
Extensions (28)
(1 theme extensions excluded)
The text was updated successfully, but these errors were encountered: