editor hangs for very long time with 7.5k file #10272

Closed
speter opened this Issue Jan 4, 2016 · 2 comments

Comments

Projects
None yet
4 participants
@speter

speter commented Jan 4, 2016

I've found similar reports when using Atom with large files but my file is less than 300 lines with less than 150 characters each.

Reproduction Steps:

  1. Download and open the file https://github.com/go-gcfg/gcfg/blob/083575c3955c85df16fe9590cceab64d03f5eb6e/set.go#L242
  2. Go to the end of line 242 (btw I find it weird that in Windows the last character is not displayed in full so the cursor at the end is also not visible)
  3. Press Enter

Expected behavior:

New line is started at L243

Observed behavior:

Atom editor window hangs for a very long time. (I thought it was indefinite but it came back after an hour or so.) After that, new line is started.

Screenshots and GIFs

screenshot

Atom version: 1.3.1 and 1.4.0beta3
OS and version: Win8.1 64bit, Debian8.2 64bit

Installed packages:

Just the core packages.

Additional information:

  • Problem can be reproduced in safe mode: Yes
  • Problem started happening recently, didn't happen in an older version of Atom: don't know
  • Problem can be reliably reproduced, doesn't happen randomly: Yes
  • Problem happens with all files and projects, not only some files or projects: No

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 9, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
Both the [^\\s()}]+ and the [^()]* match all characters besides parenthesis
literals. This redundancy can cause regex matching to have exponential cost,
a phenomenon referred to as "catastrophic backtracking". Replacing the [^()]*
with [\\s]* has the same matching behavior as the original regex and won't
catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 9, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
Both the [^\\s()}]+ and the [^()]* match all characters besides parenthesis
literals. This redundancy can cause regex matching to have exponential cost,
a phenomenon referred to as "catastrophic backtracking". Replacing the [^()]*
with [\\s]* has the same matching behavior as the original regex and won't
catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 9, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
Both the [^\\s()}]+ and the [^()]* match all characters besides parenthesis
literals. This redundancy can cause regex matching to have exponential cost,
a phenomenon referred to as "catastrophic backtracking". Replacing the [^()]*
with [\\s]* has the same matching behavior as the original regex and won't
catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 9, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
Both the [^\\s()}]+ and the [^()]* match all characters besides parenthesis
literals. This redundancy can cause regex matching to have exponential cost,
a phenomenon referred to as "catastrophic backtracking". Replacing the [^()]*
with [\\s]* has the same matching behavior as the original regex and won't
catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.
@davidvgalbraith

This comment has been minimized.

Show comment
Hide comment
@davidvgalbraith

davidvgalbraith Jan 9, 2016

I am able to reproduce this. Better yet, I am able to chase down its root cause and put together a fix: atom/language-go#79.

I am able to reproduce this. Better yet, I am able to chase down its root cause and put together a fix: atom/language-go#79.

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 10, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
Both the [^\\s()}]+ and the [^()]* match all characters besides parenthesis
literals. This redundancy can cause regex matching to have exponential cost,
a phenomenon referred to as "catastrophic backtracking". Replacing the [^()]*
with [\\s]* has the same matching behavior as the original regex and won't
catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 10, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
Both the [^\\s()}]+ and the [^()]* match all characters besides parenthesis
literals. This redundancy can cause regex matching to have exponential cost,
a phenomenon referred to as "catastrophic backtracking". Replacing the [^()]*
with [\\s]* has the same matching behavior as the original regex and won't
catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 10, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
The capturing group m: (?<m>[^()]*\\((?:\\g<m>|[^()]*)\\)[^()]*)
is prone to catastrophic backtracking because the two [^()]* outside the
parentheses literals can both match each link in a chain a()b()c()d()...
Moving the latter [^()]* inside the parentheses has the same matching
behavior as the original regex and won't catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.

davidvgalbraith pushed a commit to davidvgalbraith/language-go that referenced this issue Jan 10, 2016

Dave
decreaseNextIndentPattern: prevent catastrophic backtracking
The capturing group m: (?<m>[^()]*\\((?:\\g<m>|[^()]*)\\)[^()]*)
is prone to catastrophic backtracking because the two [^()]* outside the
parentheses literals can both match each link in a chain a()b()c()d()...
Moving the latter [^()]* inside the parentheses has the same matching
behavior as the original regex and won't catastrophically backtrack.

Fixes atom#78 and atom/atom#10272.
@lock

This comment has been minimized.

Show comment
Hide comment
@lock

lock bot Apr 22, 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

lock bot commented Apr 22, 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@atom atom locked and limited conversation to collaborators Apr 22, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.