-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Slow regexp for JSON #1080
Comments
After one more check, really having too many
|
Thanks for your precise report! This should be fixed now. |
Thank you for the fast turnaround. 👍 |
Awesome @Golmote is awesome! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Happened upon an instance for the JSON highlighting we have enabled in our product where the regexp in prism was taking a very long time (long enough to act as an effective denial of service issue on our web app).
Our user posted a JSON log containing a Java stacktrace, which included several instances of the combination of
\n\t
with lines of the stack trace between each instance. I've reduced down the entire JSON blob and found that I can cause slowness on the Prism demo with the following snippet:The perf hit appears to grow exponentially (see below) as the instances of the "\n\t" increase, such that this will probably just result in you getting a "tab not responding" message.
I haven't looked closely at the regex, but did find that the slowness occurred on the 2nd iteration of the
/"(?:\\.|[^|"])*"(?=\s*:)/gi
pattern used in tokenLoop (when set to JSON).Unfortunately I cannot debug more into the regex itself to understand, but wanted to provide the heads up on a potential string that can cripple usages of the JSON formatter.
Exponential growth as more back slashes are added to the string:
![image](https://cloud.githubusercontent.com/assets/1517997/21822006/cf319f5e-d732-11e6-944e-8727380afd38.png)
The text was updated successfully, but these errors were encountered: