Integrated Terminal Lags Intermittently

[davidzech]

• VSCode Version: 1.48.2(macOS Stable)
• OS Version: macOS Big Sur 11.0 Beta (20A5354i) (Public Beta Release 2)

Steps to Reproduce:

1. Open Terminal
2. Spam random keys until lag is experienced Press enter, then continuously type (anything) for about 2 seconds.
3. Experience a very long stutter

Does this issue occur when all extensions are disabled?: Yes

This occurs on a public beta build of macOS 11. I've confirmed the same issue on two different MacBook Pro's on the same OS version, and same VS Code version.

Attached is a performance profile. You can see the spike in the integrated terminal response time at around 23000ms - 24000ms

Profile-20200826T124154.json.zip

[edouardberthe]

@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.

[wulorn]

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

[flash-gordon]

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

[deepak1556]

Since we have narrowed down the root cause and the next step is to get a fix up in libuv. I am going to lock this thread to reduce noise, will reopen once fix is available to verify. Thanks all!

[Tyriar]

@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'

[deepak1556]

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

[akshajmody]

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.

[richardsimko]

@deepak1556 Has the fix been shipped? Because I've noticed things have gone back to normal but I don't know if it's related to me removing the code signature from all VSCode Helper apps or if it's thanks to this.

[m1nkeh]

I don't think so @richardsimko , unless it's in the insiders build?

[otimong]

Insiders build is still laggy for me

[nuBacuk]

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

[piotrsynowiec]

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

[nuBacuk]

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?

[piotrsynowiec]

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.

[focused]

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.

[deepak1556]

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.

[MaciekBaron]

Had the same issue and signature removal worked for me. Just wanted to add that the same issue was present when performing a file search, or doing a search and replace, and this was also fixed by the command.

[docwhat]

The call to lsof could be replaced with a simple C program:

#include <errno.h>
#include <libproc.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Works on macOS using libproc.

int main(int argc, char *argv[]) {
  int ret;
  pid_t pid;
  struct proc_vnodepathinfo vpi;

  if (argc == 2) {
    pid = (pid_t)atoi(argv[1]);
    ret = proc_pidinfo(pid, PROC_PIDVNODEPATHINFO, 0, &vpi,
                       PROC_PIDVNODEPATHINFO_SIZE);
    if (ret <= 0) {
      fprintf(stderr, "%s\n", strerror(errno));
      return 1;
    }
    printf("%s\n", vpi.pvi_cdir.vip_path);
  } else {
    printf("Usage: %s <pid>\n\n", argv[0]);
    printf("Print the current working directory for <pid> to stdout.\n");
  }

  return 0;
}

[dikshantpatodia]

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

[MaciekBaron]

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.

[sergerad]

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.

[wjv]

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.)

[leafac]

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

[clouedoc]

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 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 .

[itstrueimryan]

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.

[wjv]

@leafac and @clouedoc, thanks for testing that. 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)? Also, are you sure that you’re currently using the integrated Intel GPU?

The fact that this isn’t much more widely reported makes me think it only affects certain hardware configurations. But if you’re definitely seeing the VSCode issue and at the same time no keyboard lag anywhere else — especially not at the shell in Terminal — then my guess could be wrong and these issues are not connected. (But that would seem odd, since both issues seem to be addressed by using non-signed code.)

@itstrueimryan, sounds like you’re seeing the same thing I am, on a very similar hardware config. Does forcing the use of the discrete GPU (by disabling automatic graphics switching) make it better?

[leafac]

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?

[clouedoc]

I thought that my Mac was defective too. It's a 16" 2020 I've got with a discount on Amazon. I'm using integrated graphics I can't reproduce the issue either on Terminal.app or vscode anymore.

The issue also happened in other apps, such as Chrome when typing in the address bar. The issue also happened while typing code in the editor window. I used the temporary codesign fix and it worked fine. It has been driving me crazy too. I even contacted Amazon for an exchange (which they refused unless I sent my mac + password to their repair center...)

I don't really experience the issue anymore, even after updating VSCode and restarting my device.

What changed:

• Now, I mainly use my mac unplugged -> it uses the integrated graphics card
• Mac OS X updated itself

Forcing usage of the dedicated graphics cards using gfxCardStatus has no effect. So all good on my end.

[ArthurGuez]

I've also been experiencing lags using VS Code integrated terminal or Spotlight since I updated my Macbook Air (Early 2014) to Big Sur. Removing VS Code signature seemed to work for a while but that's no longer the case...

[pdkovacs]

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.)

[d-malashin]

What fixed the issue for me was running codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app.

this helped me with lags and slow terminal open

[nkaminski]

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.)

+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.

Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.

[ujwal-setlur]

How do you disable this? On Jan 25, 2021, 9:35 PM -0800, Nash Kaminski notifications@github.com, wrote:

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 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.) +1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well. Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[stellirin]

I also see the issue 'system wide', VSCode is simply the place I see it most, most notably in the integrated terminal. GPU usage is likely a placebo / red herring, I use two 4K monitors over usb-c with my MacBook Pro, which forces discrete graphics at all times, and I have the issue.

Removing the signature did appear to help for a while, but VSCode updated itself and I haven't run the command again since then.

[alexus1024]

I have experienced the problem too.

• vscode Version: 1.52.1 (and in older versions for a half of the year)
• macOs Big Sur 11.1 (20C69)
• MacBook Pro (16-inch, 2019)

Steps to reproduce:

1. open integrated terminal in vscode
2. press any letter continuously
3. after ~10 repetitions of letter there will be a hang for a second. THe hang does not repeat while on the same line.
4. press enter and try again. There will be hang again.

Tried with "terminal.integrated.shell.osx": "/bin/zsh" and "/bin/bash". Hang appears in both.

Command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app solved an issue for me. Maybe until next vscode udate.

Issue appeared some time ago. I think it appeared when I installed next macOs big update. Big Sur maybe.

[nkaminski]

@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.

[jonjaques]

+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.

Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.

Sorry to add a layer of complication to this, but I have discrete graphics switching disabled (2018 mbp) for battery and power adapter (pre-update). This term lag issue exists for me in vscode since Big Sur, but not in iterm - though I do subscribe to the beta channel and have a variety of custom settings 🤷

codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app did the trick as others have suggested.

[ay0o]

On MacBook Pro Retina 15" (Mid 2015), I can confirm this is not system-wide, only on VSCode.

iTerm2 is as smooth as ever. However, I had to use the codesign command mentioned throughout the issue to make the VSCode's built-in terminal usable again, otherwise it was a very unpleasant experience.

[docwhat]

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

[sveggiani]

@docwhat perhaps every executed/spawned process is being validated by macOs trustd service or something similar?

[docwhat]

How could we test that?

[marcello3d]

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

[pdesantis]

To piggyback on what @marcello3d said, this was affecting our own Electron app, so we built a custom version of Electron using that libuv patch and it solved the issue for us. Hopefully this will be merged upstream soon, but in the meantime, other developers can try building Electron with that patch.

[deepak1556]

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.

[deepak1556]

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

[deepak1556]

\closedWith ff85144fdd3244ffe4a5da08354667c7e57e45ef

[github-actions[bot]]

This bug has been fixed in to the latest release of VS Code Insiders!

@davidzech, you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text /verified to let us know. If not, please ensure you're on version 52838cf6799cc448e738677ec37e86cf62a5bd89 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!

[davidzech]

/verified

Insiders Build 52838cf6799cc448e738677ec37e86cf62a5bd89:

Current Stable Build 8490d3dde47c57ba65ec40dd192d014fd2113496:

[m1nkeh]

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

[darrenjennings]

oh thank God this was driving me crazy, thank you for fixing 🙏🏻