vscode: Insiders on macOS ARM64: Extension Host crashes (`SIGILL`, `EFAULT`, `EPIPE`)

Lately I have seen a crash of the extension host on macOS 11.x ARM almost daily.

@vassudanagunta @huming2207 there should be no wasm related crashes with latest insiders, this issue is mainly tracking a crash under memory pressure.

Thanks for following-up on the issue!

Most importantly, the slowdowns related to executing the git binary no longer exist. Not sure if the patch in libuv/libuv#3064 was incorporated into the Electron fork used by VSCode or macOS 11.2 just fixed that as well.

Yup the fix has been backported to our fork for early testing, the OS update has nothing to do with it.

Created https://github.com/microsoft/vscode/issues/115646, please follow the issue for updates.

Thanks @andreialecu for investigating the issue, I am adding some more info on whats known so far:

History

With apple arm64 memory protection is enabled by default for all apps, which means a memory region cannot have rwx permission https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon. But instead using pthread_jit_write_protect_np syscall a thread can switch between write and executable permission for a memory region. This is exactly what v8 did for the webassembly code path in https://chromium-review.googlesource.com/c/v8/v8/+/2378307. This patch landed in chromium 87.0.4265.0 and along with app being signed with entitlement com.apple.security.cs.allow-jit , an app will load wasm modules perfectly fine.

Whats affected Now:

Extension host process in vscode when loading wasm modules from an extension crashes. So any extension that loads wasm can be a cause: builtin js debugger, bracket pair colorizer 2 etc

Why:

The extension host process is currently forked from the chromium renderer process, so it has the same entitlement as the parent process. Also the chromium render process is able to load wasm without issues, vscode workbench uses oniguruma wasm module which is loaded in the render process.

So why only extension host ? Pending investigation. Minimal repro https://gist.github.com/deepak1556/a6d791b204978aeed549347b6c55d124

Since there are other crashes originally reported in this issue, I will split this out into separate issue to avoid confusion.

I can replicate this with all extensions disabled by starting js debugger.

macOS 11.2 production release + VSCode Insiders:

Version: 1.53.0-insider
Commit: 861a88ebadb4335df92251faf6420b598440e082
Date: 2021-01-29T21:59:10.149Z (2 days ago)
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Darwin arm64 20.3.0

I would paste the error text but it’s probably not relevant. (note that the error is slightly different than the one in the nodejs issue tracker)

@purge see: https://github.com/microsoft/vscode/issues/113410#issuecomment-754867902

The command I was using was: code-insiders --crash-reporter-directory ~/vscode-crash ..

I haven’t personally seen any SIGILLs in a long time, but if they happen frequently for you, it would likely help a lot if you can attach the crash dumps.

@deepak1556 Yes I agree. I think this is off-topic as it’s related to the permission issue https://github.com/nodejs/node/issues/37061 only.

Try --js-flags=–noexpose_wasm. It can start without warning on VSCode insider + macOS 11.1

The warning disappeared, but the extension host reports the same crash as in the screenshot I attached earlier.

Oh damn… Then I’d better stay at macOS 11.1 for now for my M1 mac…

Try --js-flags=–noexpose_wasm. It can start without warning on VSCode insider + macOS 11.1

The warning disappeared, but the extension host reports the same crash as in the screenshot I attached earlier.

If the crash continues, can you start the app with --crash-reporter-directory <some-absolute-path>, crash dumps will be generated in that location, please attach it here. Thanks!