-
-
Notifications
You must be signed in to change notification settings - Fork 373
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
StackOverFlowError still not fixed #3797
Comments
I have had this bug as well, and it has caused me a world of trouble. I’ve tried many suggestions from other threads. I’ve made my lines short (my longest line is about 15 words long), I’ve used both OpenJDK and Oracle, versions 8, 11, and 15, to no avail. This issue being fixed would make my life much easier. I should add that I am also using 1.16.5 Paper and Skript 2.5.3 |
Unfortunately the PR I have will not completely fix this either; it will
only print a more user friendly error and will not stop parsing completely
(because it is treated as a normal error and not a fatal one)
However though, it is open for fixes. Since I found exactly which regexes
cause this; fixing this would be much easier if someone knows regex (I’
dont much; and modifying blindly can break things) than before where we had
only stack traces pointing to JDK.
The error also helps and provides which line the error occurred.
If you can, testing with my PRs GH Actions build and providing feedback
would be useful.
I’ve only had this error on very long lines but is dependent on thread
stack size so you can try to increase -Xss manually (using 64 Bit Java
already increases it that is why we recommend 64 Bit Java)
If you get that constantly across machines then providing a reproducible
test script like on the issue would help, too.
|
You can also try using AdoptOpenJDK with OpenJ9 instead of default HotSpot
(do note that plugins depending on implementation specific VM features will
break like NMS) Since it has tail call optimization; it may help.
Getting a stack trace from both (different Java VMs) and potentially others
like GraalVM too may help knowing if this issue occurs on standard
HotSpot/JDK only or occurs on all Java versions/implementations.
I’ll add different JVM and Xss to the things to try suggestion in the PR
when I have time.
|
The thing I’ve read about Xss is that it increases the likelihood of a memory overflow error. I am running 64 bit Java. I’m not exactly sure how to test the PR but I will try to figure it out and let you know. edit: Not memory overflow but out of memory |
Ok, I got your pull enabled, and somehow it fixed the regex error instead of just warning me about it... |
Yes the last commit I pushed will fix it entirely for inputs not containing #. You can try the older build (before “Various optimizations” commit)
Edit: Here -
Will give errors instead of fixing on string not containing # : https://github.com/SkriptLang/Skript/suites/2205024449/artifacts/45557965
Will fix entirely for string not containing # : https://github.com/SkriptLang/Skript/suites/2212133815/artifacts/45754713
|
Description
StackOverFlowError on very long lines. Still not fixed after #3195, though that only fixed (well, not a fix but a warning) it on aliases. It still occurs on scripts. Though this an user error (having very long lines), it prints a very long stack-trace and says it to report to here, so giving a more user friendly Skript#error would be better.
Besides, it is not fully a user error. While having long script lines is often bad code, this still a Java exception and our problem. If JDK didn't used a recursive regex implementation that would not be a problem - but it is. Perhaps the regex triggering this error should be optimized. That would can speed up parsing speed, too.
Steps to Reproduce
Use this script and start the server or reload optionally.
Might want to increase the line's character count by just repeating it more if you don't get the error (the max stack size JDK option is platform dependent)
Tested on Java version (System: 64-bit Windows 10):
Can also test with Java 16 and 17 early access if desired, I don't think results will change however.
Expected Behavior
Successfully parsing and/or getting a meaningful, friendly error (in case of success, we would get an empty configuration section warning since there is no other code after the if condition)
Errors / Screenshots
Very long stacktrace repeating like this (ommitted, very very long, can provide full if desired but it doesn't contain anything related to Skript):
Server Information
Additional Context
I've managed out to find the cause on actually where this occurs on Skript side and will provide a PR.
The text was updated successfully, but these errors were encountered: