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

[analyzer] compiler crash on with while & continue #8912

Closed
RealyUniqueName opened this issue Oct 30, 2019 · 3 comments

Comments

@RealyUniqueName
Copy link
Member

@RealyUniqueName RealyUniqueName commented Oct 30, 2019

class Main {
    public static function main():Void {
        function loop() {
            while(true) {
                continue;
            }
        }
    }
}
$ haxe -main Main --interp
While analyzing Main.main
dot graph written to dump/eval/Main.main
Fatal error: exception Not_found
Raised at file "pMap.ml", line 107, characters 21-30
Called from file "src/core/define.ml", line 47, characters 5-24
Re-raised at file "src/optimization/analyzer.ml", line 1051, characters 10-13
Called from file "list.ml", line 100, characters 12-15
Called from file "src/optimization/analyzer.ml", line 1069, characters 2-53
Called from file "list.ml", line 100, characters 12-15
Called from file "src/optimization/analyzer.ml", line 1102, characters 3-43
Called from file "src/optimization/analyzer.ml", line 910, characters 10-13
Called from file "src/filters/filters.ml", line 1031, characters 31-71
Called from file "src/compiler/haxe.ml", line 602, characters 1-26
Called from file "src/compiler/haxe.ml", line 1061, characters 2-39
Called from file "src/compiler/haxe.ml", line 633, characters 3-11
Called from file "src/compiler/haxe.ml", line 1226, characters 1-35
@Simn

This comment has been minimized.

Copy link
Member

@Simn Simn commented Oct 30, 2019

That stack trace makes no sense whatsoever...

@Simn

This comment has been minimized.

Copy link
Member

@Simn Simn commented Oct 30, 2019

Actual stack trace:

Fatal error: exception Not_found
Raised at file "hashtbl.ml", line 194, characters 13-28
Called from file "src/optimization/analyzerTypes.ml" (inlined), line 343, characters 19-38
Called from file "src/optimization/analyzerTypes.ml", line 387, characters 13-23
Called from file "src/optimization/analyzerTypes.ml", line 399, characters 13-36
Called from file "list.ml", line 121, characters 24-34
Called from file "src/optimization/analyzerTypes.ml", line 398, characters 15-110
Called from file "src/optimization/analyzerTypes.ml", line 417, characters 2-19
Called from file "src/optimization/analyzer.ml", line 910, characters 10-13
Called from file "src/optimization/analyzer.ml", line 1014, characters 2-107
Called from file "src/optimization/analyzer.ml", line 1045, characters 4-22
Called from file "list.ml", line 110, characters 12-15
Called from file "src/optimization/analyzer.ml", line 1069, characters 2-53
Called from file "list.ml", line 110, characters 12-15
Called from file "src/optimization/analyzer.ml", line 1102, characters 3-43
Called from file "src/optimization/analyzer.ml", line 910, characters 10-13
Called from file "src/filters/filters.ml", line 893, characters 31-71
Called from file "src/compiler/haxe.ml", line 602, characters 1-26
Called from file "src/compiler/haxe.ml", line 1061, characters 2-39
Called from file "src/compiler/haxe.ml", line 633, characters 3-11
Called from file "src/compiler/haxe.ml", line 1226, characters 1-35

Something wrong in the idom calculation.

Simn added a commit that referenced this issue Oct 30, 2019
@Simn Simn added test-needed and removed bug labels Oct 30, 2019
@Simn

This comment has been minimized.

Copy link
Member

@Simn Simn commented Oct 30, 2019

Should be fixed, needs a test still.

The problem here was that we usually add a pseudo-CFG-edge from the loop body to the loop exit in order to not have a disconnected graph. In the case of an unconditional continue, the end of the loop body is reported as being the unreachable block and adding any edges from there isn't helping in any way.

I've changed it to add that pseudo-edge from the loop body entrypoint instead, which is never the unreachable block. This has the same semantics because all we really care to do here is making the loop exit reachable in the graph.

@skial skial referenced this issue Oct 31, 2019
1 of 1 task complete
RealyUniqueName added a commit that referenced this issue Oct 31, 2019
closes #8912
RealyUniqueName added a commit that referenced this issue Oct 31, 2019
RealyUniqueName added a commit that referenced this issue Oct 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.