search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
161.24k stars 28.31k forks source link

Integrated Terminal Lags Intermittently #105446

Closed davidzech closed 3 years ago

davidzech commented 3 years ago

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

image

Profile-20200826T124154.json.zip

davidzech commented 3 years ago

It seems like https://github.com/microsoft/vscode/blob/f74e473238aca7b79c08be761d99a0232838ca4c/src/vs/workbench/contrib/terminal/node/terminalProcess.ts#L276 is taking a long time.

davidzech commented 3 years ago

Benchmarking this call, it takes on average 800ms. It doesn't make sense, but this seems to be a Node.js x macOS beta type of issue.

festiveelephantseal commented 3 years ago

I have been having this issue as well with the insiders build of vscode

Tyriar commented 3 years ago

@deepak1556 do you know why an exec call would be blocking the thread?

davidzech commented 3 years ago

Some further notes for reference:

Monkey patching https://github.com/microsoft/vscode/blob/a4befc3d68695645063a257493eec7957d4f7064/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts#L1194

to be 

async() => { this._updateProcessCwd(); }

Seems to fix the terminal from being blocked. It's still a bandaid over the underlying problem, which is child_process.exec() taking a long time to execute on macOS Big Sur Beta.

Edit: I was wrong, still exhibits the behavior, weird.

matinzd commented 3 years ago

+1 I have this issue either and it happened after updating to macOS 11 (Big Sur) beta. I am currently on beta 9 and the issue still exists.

UPDATE: I have the lag even if I am typing or running commands and its so annoying. 

Version: 1.50.0
Commit: 93c2f0fbf16c5a4b10e4d5f89737d9c2c25488a3
Date: 2020-10-07T06:00:00.397Z (6 days ago)
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 20.1.0
tolgaerdonmez commented 3 years ago

+1 I have this issue either and it happened after updating to macOS 11 (Big Sur) beta. I am currently on beta 9 and the issue still exists.

Version: 1.50.0
Commit: 93c2f0fbf16c5a4b10e4d5f89737d9c2c25488a3
Date: 2020-10-07T06:00:00.397Z (6 days ago)
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 20.1.0

It also occurred with me after updating to Big Sur Beta, I think it is about the beta.

davidzech commented 3 years ago

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

Vardiak commented 3 years ago

@davidzech Don't you think this might be a bug from the macOS kernel then?

Adam2Marsh commented 3 years ago

+1 for having this issue; only remember seeing this issue after upgrading to Big Sur. Happy to run some debugging if anyone has any ideas.

Thanks.

davidzech commented 3 years ago

@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

image

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

KangDroid commented 3 years ago

@davidzech +1 Agree, I built Code-OSS[master branch] with macOS 11.0.1[build = 20B5012d] and I see no problem with input-lag with integrated terminal. Only for local build. Public version of vscode still has that problem tho.

deepak1556 commented 3 years ago

Thanks for narrowing down the issue @davidzech , we do use a custom electron build for the stable and insiders while we use https://electronjs.org/ releases for the OSS build. But I don't see any patches around the child_process code path.

Can you run the test on following electron builds, you can extract and run the electron binary, toggle developer tools from the View menu

KangDroid commented 3 years ago

@deepak1556

I've done some quick-test, by swapping Electron binaries on latest stable release vscode, both custom electron | oss electron. The issue still remains.

Also I bulit vscode-darwin[oss package] and swapped electron binaries with custom electron version, there is no issue at all. Which might indicates it is not the problem of electron[perhaps?]

It might be a useful information[or not really] that Commit information of current stable version of release is d2e414d9e4239a252d1ab117bd7067f125afd80a. So I reverted source of vscode to that commit and built code-oss, there was no problem at all.

deepak1556 commented 3 years ago

Also I bulit vscode-darwin[oss package] and swapped electron binaries with custom electron version, there is no issue at all. Which might indicates it is not the problem of electron[perhaps?]

Interesting, then this might indicate the problem is with a packaged app vs running out of sources. @davidzech are you aware of any entitlement changes in big sur that would impact this ?

davidzech commented 3 years ago

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

deepak1556 commented 3 years ago

I don't think there is much to debug on electron or vscode end, would like to report this issue to apple. What is best way to do it ?

bmstefanski commented 3 years ago

Last os update resolves the issue for me

OS: macOS Big Sur 11.0.1 20B5022a x86_64 Kernel: 20.1.0 VSCode: 1.51

flash-gordon commented 3 years ago

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

yay commented 3 years ago

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

marcello3d commented 3 years ago

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

matinzd commented 3 years ago

This may be an Electron bug since we had these problems on Big Sur when on release.

ezgif com-gif-maker

Zehua-Chen commented 3 years ago

I am on macOS Big Sur 11.0.1. In addition to the terminal freezing, every time I switched back to the code editor from the terminal, the code editor would also freeze.

jaikens19 commented 3 years ago

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

paulfsheridan commented 3 years ago

@jaikens19 Same issue here.

jaikens19 commented 3 years ago

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

findtravishere commented 3 years ago

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.

etpstevenk commented 3 years ago

I am experiencing the same

paulfsheridan commented 3 years ago

@jaikens19, unfortunately, had no luck with this. Thanks though.

caburj commented 3 years ago

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

itsjoeoui commented 3 years ago

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

tolgaerdonmez commented 3 years ago

@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 also worked for me, thanks!

kwent commented 3 years ago

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

pixelomer commented 3 years ago

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

matinzd commented 3 years ago

@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 workaround worked for me too ;)

lenaschimmel commented 3 years ago

Has anybody checked if this is related to Apple's recent usage of OSCP to check the validity of developer certificates when launching an executable? According to that blog post, this should only happen once for each executable, so I guess this is something else. Also, maybe I'm mixing up signatures and certificates here?

marcello3d commented 3 years ago

@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

rhyek commented 3 years ago

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

herberthobregon commented 3 years ago

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

memeplex commented 3 years ago

I'm having this issue in Big Sur and removing signature as suggested above "fixes" it.

aviramha commented 3 years ago

I am affected also by this.

dylvaz commented 3 years ago

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.

JeffreyCA commented 3 years ago

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?

dylvaz commented 3 years ago

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.

piotrsynowiec commented 3 years ago

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.

It's lagging as it was, and now Little Snitch tells me that VSCode is not signed and it's probably a malware.

Could you share with me how can is sign it again? Re-Installing the app didn't change much.

davidzech commented 3 years ago

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.

deepak1556 commented 3 years ago

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.

srubin commented 3 years ago

@deepak1556 Yes, I just confirmed that the problem exists in the browser process (electron "main") with the latest nightly.

deepak1556 commented 3 years ago

thanks for confirming!

jchappelle commented 3 years ago

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