haxe-checkstyle
haxe-checkstyle copied to clipboard
Silent crash on Windows with very long line
Checkstyle dies on this line:
https://github.com/HaxeFlixel/flixel/blob/4.2.0/flixel/graphics/frames/FlxBitmapFont.hx#L31
And apparently only on Windows.
Easiest way to reproduce is to clone the flixel repo and run haxelib run checkstyle -s . -progress
- FlxBitmapFont.hx
will be the last file displayed before it exits.
I know that line is the one causing the problem because it works fine after it's removed.
I took a quick look at the issue on a Windows 10 machine, here is what I found:
neko.exe
crashes in regexp.ndll
with a stackoverflow
I have narrowed it down to line based checks (tested with IndentationCharacter
, TabForAligning
, TrailingWhitespace
), so I guess it has to do with the multiline / string detection stuff.
Hm, I guess it must be a Neko bug then. :/ Perhaps it's trying to run a regex over that long line and the regex engine can't handle strings that long on Windows for some reason?
I think it might be more of an "evil" regex problem ( https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS ) Maybe it works on Linux / OSX, because neko uses larger stacksizes on those systems. Just wild guesses, I haven't looked any further.
A solution might be to change our regexes, so that there is less need for backtracking or recursion. Though I'm not sure if that's possible.
We should definitely at least find a workaround for crashes like this... Though that might be tricky. Maybe some heuristic like "if the line is longer than x characters, don't risk it". :/
As a workaround we could make lines above 1000 (or 2000, needs testing) spit out a checkstyle message for all line based checks. So that users get some kind of feedback on those files, and can fix line length or exclude checks.
A more stable solution might be to go hybrid as proposed in #278, where comment and string detection comes though token tree. But that will come with some performance impact.
I doubt that's necessary, this seems like a pretty rare edge case considering it hasn't come up until now.
Just ran into what seems like this issue as well. In particular on the TabForAligning
, EmptyLines
, and IndentationCharacter
checks.
We don't use the TrailingWhitespace
check. All these checks extend LineCheckBase
.
Neko returning 3221225725, which is apparently a stack overflow?
Happy to investigate a fix and do a pull request. What version of haxe should I be using to build?
To add it was also due to an extremely long line in a test.
I understand the priority is pretty low due to it being an edge case, but its taken me a good couple hours to track down. So again, let me know what compiler version I should be using and I will attempt a fix.
I would recommend Haxe 4rc5 for compiling git checkstyle.
I haven't done extensive tests, but it seems running a nodejs version of checkstyle might be bit more reliable.
Maybe we need to do the same nodejs switcheroo as we do with formatter. And maybe I should make that checkstyle release, that I keep postponing...