neko icon indicating copy to clipboard operation
neko copied to clipboard

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

Open flashultra opened this issue 3 years ago • 4 comments

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 .

flashultra avatar Sep 30 '22 13:09 flashultra

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 avatar Mar 24 '23 09:03 Simn

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

Simn avatar Mar 30 '23 15:03 Simn

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.

tobil4sk avatar Apr 10 '23 13:04 tobil4sk

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

Simn avatar Apr 10 '23 14:04 Simn