vscode: Integrated Terminal Lags Intermittently

Thanks for the reports, we will soon have a fix from electron and libuv for this issue, will report back once the fix has been released.

@deepak1556 I am not aware of anything intentional, but I can confirm that stripping code signature from Code Helper (Renderer) makes the problem go away.

You can test with codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app

So unfortunately, it looks like my guess from https://github.com/microsoft/vscode/issues/107103#issuecomment-696454728 looks to be accurate.

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app

it ended up fixing the issue for me.

/verified

Insiders Build 52838cf6799cc448e738677ec37e86cf62a5bd89:

Current Stable Build 8490d3dde47c57ba65ec40dd192d014fd2113496:

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app

it ended up fixing the issue for me.

This worked for me.

The libuv fix has been backported internally and is available in latest insiders, please verify if this issue is fixed. Thanks!

FYI, the fix is reverted in electron but I have added workarounds for the failing test cases mentioned in the libuv repo while it is being investigated, so I have not reverted the fix internally for vscode.

The command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app worked for me, but each time after restart OSX I need to execute it again.

After entering this command I only need to restart VSCode, not my mac.

I don’t think its a good idea to remove the signature.

Instead do the following:

1. Open terminal in VS code
2. Open to-right dropdown in terminal and select Select Default Shell
3. Here select sh /bin/sh

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

Many users will want to use bash or zsh for example (myself included). So this is not an appropriate solution in those cases.

I don’t think its a good idea to remove the signature.

Instead do the following:

1. Open terminal in VS code
2. Open to-right dropdown in terminal and select Select Default Shell
3. Here select sh /bin/sh

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

This issue is still persisting for me. In general I’m noticing a small lag in typing even when using Slack but definitely the most lag is with VScode terminal where it freezes for a whole second or so every now and then.

Above fix works for me as well. Don’t forget to relaunch vscode.

I got an update of the non-insiders today, and no issues that I could see either, weird… v1.53

I ran the command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app and am still experiencing lagging in terminal. On macOs 11.0.1.

Did you relaunch VS Code?

Don’t hurt me but it worked after I relaunched lol.

Are there any drawbacks to removing the signature as suggested? Perhaps related to future updates?

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app

it ended up fixing the issue for me.

I can confirm this worked for me as well!

Same issue, thought there was something wrong with my laptop. On top of the delay in the terminal, i’m experiencing delay while typing and backspacing continuously both in terminal and while working on any files.

Heads up, the fix was reverted upstream: https://github.com/libuv/libuv/issues/3050#issuecomment-778495429

I’m not sure what that means for VSCode or if this issue should be reopened? I guess maybe it depends on how Electron handles this.

Pls stop posting “it works”/“it helped me” comments, use 👍

Aha that would also explain why the issue is not seen for child processes forked from browser process as reported by @marcello3d in the electron issue. The reason being until recently https://github.com/electron/electron/pull/26331 we have been using a different memory allocator on the browser process that doesn’t MAP_JIT regions allocated, hence fork didn’t have JIT regions to copy over. If this is true, @marcello3d you should see this issue in browser process with nightly release of electron https://www.electronjs.org/releases/nightly, can you confirm ?

It would be nice if libuv used posix_spawn instead.

@davidzech there seems to be an active issue about using posix_spawn for a different scenario on all platforms https://github.com/libuv/libuv/issues/2133 , lets continue the discussion in the electron thread https://github.com/electron/electron/issues/26143 so that the team can drive the effort to make the change atleast on macOS to circumvent this issue.

Having the same issue on VSCode as well. Upgraded to Big Sur from Catalina last night and started having the freezing issue instantly.

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)

I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I’m a fairly quick touch typist.)

The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)

Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.

I tried to see if @davidzech’s suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app +1 thanks.

You’re just removing the signature from the original app. Signatures are meant to prove the app came from a certain developer. If you know that this app you downloaded is legit, then there is no danger in removing the signature. I GUESS ⚠️⚠️⚠️⚠️.

This looks similar to a problem we found: https://github.com/electron/electron/issues/26143

It seems to an Electron bug since it’s reproducible when using child_process.spawn in the renderer process but not in main

@Adam2Marsh Have you built locally? To my surprise, I ran my tests on master and tag 1.50.1 and I do not experience this lag at all, yet is persistent in both Stable and Insider public releases.

An useful bisection perhaps.

See

Edit 2: VSCodium also doesn’t exhibit this behavior for me.

FYI the root cause has already been tracked down and being fixed in libuv/electron, see:

• https://github.com/microsoft/vscode/issues/105446#issuecomment-730342806 (a comment on this issue)
• https://github.com/electron/electron/pull/27026
• https://github.com/libuv/libuv/pull/3064

@wjv I typed ls<enter> more than 20 times and couldn’t reproduce what you described.

Thanks @Tyriar , I am opening the issue for users to verify the temporary fix.

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app

it ended up fixing the issue for me.

Worked like a charm for me also! Installed Big Sur 2 days ago, the bug immediately appeared, and your command immediately solved it, thanks.

On macOS 11.0.1, fork() seems to physically copy all JIT memory regions (no-copy-on-write). On previous OS, these regions weren’t accessible at all in the forked process, sort of explaining the “regression”.

You can test by making a lot of mmap() calls with MAP_JIT, and then calling fork() in a playground project. (make sure you have com.apple.security.cs.allow-jit entitlement)

It would be nice if libuv used posix_spawn instead.

I am experiencing the same

Unfortunately it doesn’t work for me, but I have a question – is removing this signature a good choice in terms of security measures?

completely restarted the application?

I’ve restarted the app & the mac. The app is still laggy.

it helped me codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app

Insiders build is still laggy for me

I ran the command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app and am still experiencing lagging in terminal. On macOs 11.0.1.

Some further insights:

I have done some debugging with lldb, and have narrowed it down to fork() being the bottleneck here.

Edit: You can observe calls with sudo dtruss -p <window_pid> -t fork -e

I couldn’t reproduce typing ls<enter> multiple times.

On Sat, Jan 23, 2021 at 6:01 PM Leandro Facchinetti < notifications@github.com> wrote:

@wjv https://github.com/wjv I typed ls<enter> more than 20 times and couldn’t reproduce what you described.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/105446#issuecomment-766141286, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKG2SXFERBOKPBJUIWG4RTS3L6FBANCNFSM4QMGKECA .

I don’t think removing the signature can cause any harm, its main purpose is to secure software distribution and verifying the original executable. Once you have downloaded the verified executable and removed the signature, this shouldn’t open up any security holes, unless your system is already infected.

I might be wrong though - would be nice to learn if there is a possible attack vector here.

@jaikens19 Same issue here.

The issue persists with the latest macOS 11.0.1 RC2 released today. Stripping the signature helped though.

@leafac the fix is available in the insiders builds only as of now. Switch to insiders builds or stick to the codesign workaround for the time being.

@ay0o the update should have installed a new signed binary

so, what’s the correct way of undoing codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app.

Guess we need to sign the app again. But with which key?

Thanks @marcello3d @pdesantis for the work on fix.

Just to update, whenever upstream releases a new version with the patch vscode will update to it. Also we didn’t build the patch internally because it was too late in the current January iteration to get enough testing before stable release 1.53 that will happen next week. We will get this fix in to our internal builds next February iteration for early testing if there is no release from upstream.

I see that the issue is getting side tracked again, will lock until further updates.

Does anyone have a theory for why removing the signature “fixes” the problem that we can test?

@ujwal-setlur To turn off automatic graphics switching, go to system preferences > Battery > Automatic Graphics Switching and uncheck the box.

Be aware that this results in a ~30% battery life reduction.

Re possible system-wide issue brought up by @wjv : Since upgrading to Big Sure, I am experiencing a terrible lag during login with a 2018 MacMini most recent Magic Keyboard combo. Even characters are dropped when entering my password, so I have to type characters at least 1 second (sometimes longer) apart to make sure each of them gets registered. Note that since FileVault is turned on, the login is preceding any actual system startup activity. (My password is needed to unlock the system files as well, AFAIK.)

Are you saying that you are observing the VSCode behaviour that’s the subject of this Issue, but not seeing the problem in Terminal (or elsewhere)?

👍 Exactly.

What fixed the issue for me was running codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app. I tested Terminal.app after having ran this (but it shouldn’t matter, because Terminal.app has nothing to do with Code Helper (Renderer).app).

Also, are you sure that you’re currently using the integrated Intel GPU?

I suppose I am because that’d be the only option:

How do I check?

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)

I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I’m a fairly quick touch typist.)

The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)

Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.

I tried to see if @davidzech’s suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

I’ve been experiencing this since upgrading to Big Sur (16 inch, 2019 Mac). It’s driving me crazy.

Removing the certificate worked for me to speed up the integrated terminal in VSCode, but in general I still experience that intermittent keyboard lag you’re talking about, even as I type this message, generally a few hundred milliseconds to a half a second but certainly very noticeable.

@deepak1556 I wasn’t able to test it, but I’ve disable this lsof call on Big Sur+, here’s the workaround that we will want to remove when the fix lands in Electron:

https://github.com/microsoft/vscode/commit/d964664da291f28372a02d3d7ce82d650a98c890

All this should do is disable current working directory-based links, so relative links will only work from the initial directory. This won’t work for example:

cd src 
echo './somefile'

This started happening for me when I upgraded to macOS Big Sur 11.0.1. Here’s the vscode version info.

Version: 1.51.1
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-11T01:11:34.018Z (1 wk ago)
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 20.1.0

I ran the command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app and am still experiencing lagging in terminal. On macOs 11.0.1.

Did you relaunch VS Code?

@lenaschimmel: yea, I looked at that, and it appears to be unrelated. it happens even if wifi/ethernet are off, and it’s only reproducible in the electron renderer process, not the main process

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app

it ended up fixing the issue for me.

This fix seems to work for me as well.

I cannot confirm this, installed the latest beta yesterday. The terminal had been laggish until I stripped the signature.