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

[neko] Uncaught exception - load.c(398) : Invalid module #283

Closed
flashultra opened this issue Sep 30, 2022 · 4 comments · Fixed by #284
Closed

[neko] Uncaught exception - load.c(398) : Invalid module #283

flashultra opened this issue Sep 30, 2022 · 4 comments · Fixed by #284
Assignees

Comments

@flashultra
Copy link

flashultra commented Sep 30, 2022

The following code return the error Uncaught exception - load.c(398) : Invalid module : bin/unit.n for neko target ( 2.2.0 , 2.3.0 and 2.3.1 )

		var r:Vector<haxe.Int64> = new Vector<haxe.Int64>(5);
		var h:Vector<haxe.Int64> = new Vector<haxe.Int64>(5);
		var s:Vector<haxe.Int64> = new Vector<haxe.Int64>(4);

		for (i in 0...5) {
			r[i] = 0;
			h[i] = 0;
		}

		for (i in 0...4) {
			s[i] = 0;
		}

		var t0:haxe.Int64 = h[0] * r[0] + h[1] * s[3] + h[2] * s[2] + h[3] * s[1] + h[4] * s[0];
		var t1:haxe.Int64 = h[0] * r[1] + h[1] * r[0] + h[2] * s[3] + h[3] * s[2] + h[4] * s[1];

If you comment the last row var t1:.... or t0 it's start to compile .

@Simn
Copy link
Member

Simn commented Mar 24, 2023

I'm assigning 4.3 because while this is neko and probably some weird corner case, I'm actually quite curious what happens here.

@Simn Simn self-assigned this Mar 24, 2023
@Simn
Copy link
Member

Simn commented Mar 30, 2023

Sadly, I don't have the time to look into this for 4.3.

@tobil4sk
Copy link
Member

The problem is that the Int64 code generates a lot of local variables in the same function scope. This issue can also be reproduced with this sample:

@:analyzer(no_optimize)
function main() {
    var _:Int; // 1
    var _:Int; // 2
    var _:Int; // 3
    ...
    var _:Int; // 124 - this line goes over the limit
}

Neko has a stack limit size of 124 per scope, and defining this many local variables exceeds this stack limit, which causes the bytecode checks to fail. https://github.com/HaxeFoundation/neko/blob/master/vm/module.c#L143-L144

This isn't exclusive to Haxe. It's possible to write native Neko code that also triggers this failure. It can be worked around by splitting the code into separate scopes using { } blocks.

I don't see Haxe being able to do much about this, apart from maybe optimising the haxe.Int64 code to generate fewer temporary variables (right now it generates a lot for 0i64 * 0i64, and analyzer doesn't help). It could try to detect when variables are not used again and group them into smaller scopes, but that seems more like a (hypothetical) job for the Neko compiler.

I guess the Neko error could also be a bit more specific as well.

@Simn
Copy link
Member

Simn commented Apr 10, 2023

I'll transfer this to neko because if anything, we'll improve the error message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants