Skip to content
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

Using integrated terminal to cat file with lots of unicode hangs terminal #24795

Closed
xavdid opened this issue Apr 14, 2017 · 23 comments
Closed

Using integrated terminal to cat file with lots of unicode hangs terminal #24795

xavdid opened this issue Apr 14, 2017 · 23 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug freeze-slow-crash-leak VS Code crashing, performance, freeze and memory leak issues terminal Integrated terminal issues verified Verification succeeded
Milestone

Comments

@xavdid
Copy link

xavdid commented Apr 14, 2017

  • VSCode Version: 1.11.2
  • OS Version: macOS 10.12.4

Steps to Reproduce:

  1. Open integrated terminal
  2. cat a file with a lot of unicode. I found it with this file, but anything with a lot of printed unicode (eg validate\n#Validating project locally.\n#\n# \u250C\u2500\u2500\u2500\u2500\u2500\u2500\u2500 ... should work

The terminal window is unable to scroll while the unicode characters are visible. When it does recover, it scrolls normally when looking at previous lines. Scrolling down to the unicode block hangs it again.

Repro Rate: 100%

@Tyriar
Copy link
Member

Tyriar commented Apr 18, 2017

I cannot reproduce using fish or bash. What's in your settings.json?

@Tyriar Tyriar closed this as completed Apr 18, 2017
@Tyriar Tyriar added terminal Integrated terminal issues info-needed Issue requires more information from poster labels Apr 18, 2017
@xavdid
Copy link
Author

xavdid commented Apr 18, 2017

Sorry, this is in zsh (v5.2) with oh_my_zsh enabled.

I recorded a quick example video here: https://www.youtube.com/watch?v=lkpLyl8_miE

I can scroll normally before the file is viewed, can't once it's there. After ~ 30 sec, the dead window dialog shows:

screen shot 2017-04-18 at 3 33 40 pm

It closes properly. If I keep waiting, the Code Helper process jumps to 98% CPU usage and in another 30 sec, the dialog pops up again.

@xavdid
Copy link
Author

xavdid commented Apr 18, 2017

my settings.json is here:

// Place your settings in this file to overwrite the default settings
{
    "editor.autoClosingBrackets": false,
    "files.trimTrailingWhitespace": true,
    "files.exclude": {
        "**/.git": true,
        "**/.svn": true,
        "**/.hg": true,
        "**/.DS_Store": true,
        "**/node_modules/**": true,
        "**/.sass-cache/**": true,
        "**/.bundle": true,
        "*.map.js": true,
        "dist": true
    },
    "editor.fontFamily": "Iconsolata, Monaco, 'Courier New', monospace",
    "window.zoomLevel": 0,
    "editor.wordWrap": "on",
    "editor.formatOnPaste": true,
    "editor.folding": true,
    "diffEditor.renderSideBySide": false,
    "standard.autoFixOnSave": true,
    "tslint.autoFixOnSave": true,
    "editor.tabSize": 2,
    "files.insertFinalNewline": true,
    "workbench.welcome.enabled": false,
    "workbench.colorTheme": "Monokai",
    "editor.minimap.enabled": false,
    "files.associations": {
      "Brewfile": "ruby"
    },
    "eslint.enable": false,
    "eslint.autoFixOnSave": true,
    "extensions.autoUpdate": true,
    "ruby.lint": {
      "rubocop": false,
      "ruby": true
    },
    "workbench.iconTheme": "vs-seti"
  }
}

@Tyriar
Copy link
Member

Tyriar commented Apr 19, 2017

@xavdid I notice the file is in the terminal rendered correctly before you run cat, how did you print that?

@Tyriar Tyriar added the freeze-slow-crash-leak VS Code crashing, performance, freeze and memory leak issues label Apr 19, 2017
@xavdid
Copy link
Author

xavdid commented Apr 19, 2017

Ah, that was the same file without the unicode. I tried it to ensure the unicode characters were the issue (not cat or something else in the file).

@Tyriar
Copy link
Member

Tyriar commented Apr 19, 2017

But there are still unicode characters in that file though, no? Like this one

@xavdid
Copy link
Author

xavdid commented Apr 19, 2017

oh, you're totally right. The first copy of the file is this, which has the actual unicode and works fine.

The non-working one is after that file's been run through babel and the unicode replaced with a string (\u2514 & co). That's available here. Thanks for your patience here!

@Tyriar
Copy link
Member

Tyriar commented Apr 20, 2017

Oh ok, so no issue then 👍

@xavdid
Copy link
Author

xavdid commented Apr 20, 2017

I mean, there's still the hang displaying /u2514. I was mistaken in describing it, but there's definitely a bug.

@Tyriar
Copy link
Member

Tyriar commented Apr 21, 2017

@xavdid could you try running VS Code using code --verbose and pasting in the output after the hang/crash?

@Tyriar Tyriar reopened this Apr 21, 2017
@xavdid
Copy link
Author

xavdid commented Apr 21, 2017

Sure thing!

% code --verbose
[main 11:02:16 AM] Starting VS Code in verbose mode
[main 11:02:16 AM] from: /Applications/Visual Studio Code.app/Contents/Resources/app
[main 11:02:16 AM] args: { _: [],
  help: false,
  h: false,
  version: false,
  v: false,
  wait: false,
  w: false,
  diff: false,
  d: false,
  goto: false,
  g: false,
  'new-window': false,
  n: false,
  'unity-launch': false,
  'reuse-window': false,
  r: false,
  performance: false,
  p: false,
  'prof-startup': false,
  verbose: true,
  logExtensionHostCommunication: false,
  'disable-extensions': false,
  disableExtensions: false,
  'list-extensions': false,
  'show-versions': false,
  nolazy: false }
[76592:0421/110218:INFO:CONSOLE(28)] "Conflict detected, command `workbench.action.terminal.clear` cannot be triggered due to workbench.action.showErrorsWarnings", source: file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js (28)
[main 11:02:18 AM] IPC#vscode-workbenchLoaded
[VS Code]: detected unresponsive

anecdotally, having the window half (instead of full) width helped. When I would resize it, the terminal wouldn't wrap appropriately. That is, going from half -> full the text in the terminal was still unresponsive and wrapped at the half width.

@wrauner
Copy link

wrauner commented Apr 21, 2017

It seems that I found another string that crashes integrated terminal. Running same VSCode version and OS, I can reproduce similar behavior using string

\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x

either by cat'ing it from a file or simply by pasting it into integrated terminal. I debugged the source code and the problem seems to start in xterm module, Linkifier class, _findLinkMatch method, line 242.

const match = text.match(regex);

after matching text (repeated x's) against regex:

/(((\.\.?|\~)|([^\0\s!$`&*()\[\]+'":;]|(\\s|\\!|\\$|\\`|\\&|\\*|(|)|\+))+)?(\/([^\0\s!$`&*()\[\]+'":;]|(\\s|\\!|\\$|\\`|\\&|\\*|(|)|\+))+)+)/

application becomes unresponsive. Hope that my findings can help you solve the issue.

@Tyriar
Copy link
Member

Tyriar commented Apr 24, 2017

@wrauner wow, great repro steps!

I think this is a case of 'catastophic backtracking' http://www.regular-expressions.info/catastrophic.html

@Tyriar Tyriar added bug Issue identified by VS Code Team member as probable bug and removed info-needed Issue requires more information from poster labels Apr 24, 2017
@silasjmatson
Copy link

silasjmatson commented Aug 4, 2017

I've also experienced this issue.

Using zsh on macOS Sierra.

$ zsh --version
zsh 5.2 (x86_64-apple-darwin15.4.0)

@rmunn
Copy link
Contributor

rmunn commented Aug 17, 2017

In a comment on a now-closed duplicate report, I discovered that VS Code was becoming unresponsive for X seconds, where X was directly proportional to (2 ^ length of string). E.g., if a string that could trigger the bug was pasted in, and that string was 21 characters long, I found that VS Code was freezing for about 4.5 seconds. If I added one more hex escape to the end of the string, that 22-character string would freeze VS Code for 9 seconds. A 23-character string would freeze for 18 seconds, a 24-character string would freeze for 36 seconds, and a 25-character string would freeze for 72 seconds. (I stopped at 25 characters since the pattern was clear at that point).

@rmunn
Copy link
Contributor

rmunn commented Aug 17, 2017

And since it hasn't been mentioned yet, I can also reproduce this on Linux (using the bash shell), but not on Windows. Which seems consistent with @wrauner's finding that the problem seems to be in the xterm module of the integrated terminal, since I assume that that module isn't used in the Windows build of VS Code.

@Tyriar
Copy link
Member

Tyriar commented Aug 17, 2017

The xterm module is used in Windows, things are handled a little differently though as pseudoterminals are emulated via the node-pty module (as opposed to being a native concept on Linux/macOS).

Windows uses slightly different path regexes due to different formats which is probably the reason if it doesn't happen on Windows.

@justlurking
Copy link

justlurking commented Aug 27, 2017

Any movement on solving this bug? I have the exact same issue with Unicode characters. Terminal window will not scroll for several seconds, while the Code - helper" process runs at 100% of CPU. Eventually VS Code will stop responding altogether, and I'll get the "wait or close" prompt.

I switched from Atom to VS Code for the integrated Terminal and have found the terminal completely unusable due to this issue and the work that I'm doing.

VSCode Version: 1.15.1 and 1.16-insider
OS Version: macOS 10.12.6

I've tried the insiders build, and also tried launching "code-insiders --disable-extensions" without any improvement. Repros 100% of the time. My settings file:

{ "editor.fontSize": 15, "terminal.integrated.fontSize": 14, "extensions.ignoreRecommendations": false, "window.zoomLevel": 0 }

I've also checked the developer tools console. There are no info/warnings/errors, but under verbose logging I do see the following:

[Violation] 'setTimeout' handler took 21294ms
18:56:08.251 Terminal.ts:1076 [Violation] Handling of 'wheel' input event was delayed for 20800 ms due to main thread being busy. Consider marking event handler as 'passive' to make the page more responsive.
18:56:10.943 [Violation] 'setTimeout' handler took 2685ms
18:56:32.275 [Violation] 'setTimeout' handler took 21126ms
18:56:32.441 [Violation] 'setTimeout' handler took 165ms
18:56:32.939 [Violation] 'setTimeout' handler took 166ms
18:56:33.265 [Violation] 'setTimeout' handler took 325ms
18:56:43.882 [Violation] 'setTimeout' handler took 10616ms
18:56:46.522 [Violation] 'setTimeout' handler took 2639ms
18:56:46.726 [Violation] 'setTimeout' handler took 163ms
18:56:47.383 [Violation] 'setTimeout' handler took 656ms
18:56:47.562 [Violation] 'setTimeout' handler took 163ms

Please let me know if I can provide any additional information to help track down and squash this bug. Thanks!

@Tyriar
Copy link
Member

Tyriar commented Aug 30, 2017

I believe it's caused by one of these regexes:

https://github.com/Microsoft/vscode/blob/e38f1d18c7e72690c8f19a1a28fb1369431ea75a/src/vs/workbench/parts/terminal/electron-browser/terminalLinkHandler.ts#L19-L24

The problem is that Chromium can't detect catastrophic backtracking cases and won't stop working until it finishes executing the regex. Can't even hide it in a setTimeout because it will still block. Any help on whether we can improve the regex without losing the link functionality would be helpful.

@Tyriar
Copy link
Member

Tyriar commented Aug 30, 2017

@rebornix can you see anything blatantly wrong in those regexes?

@Tyriar Tyriar closed this as completed in 4b9eaeb Aug 30, 2017
@Tyriar
Copy link
Member

Tyriar commented Aug 30, 2017

Nevermind, I fixed it. I just disallowed \ characters in unix paths for the greater good.

Thanks for the push @justlurking, should make it into v1.16.0 😉

@Tyriar Tyriar added this to the August 2017 milestone Aug 30, 2017
@xavdid
Copy link
Author

xavdid commented Aug 30, 2017

awesome, thank you!

@justlurking
Copy link

justlurking commented Aug 30, 2017

Fantastic; thanks @Tyriar!

@mjbvz mjbvz added the verified Verification succeeded label Aug 31, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug freeze-slow-crash-leak VS Code crashing, performance, freeze and memory leak issues terminal Integrated terminal issues verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

7 participants