Std.int(hl.UI8) causes jit error on linux

[shakesoda]

Anything to do with int<->UI8 conversions seems to be blowing up on linux jit. this currently breaks jit for my game (c builds are fine).

repro:

class Test {
	static function explode(v: hl.UI8) {
		trace(Std.int(v));
	}
	static function main() {
		explode(5);
	}
}

output: JIT ERROR 0 (jit.c line 517)

tested on ubuntu 16.04 and 18.04, latest commit of haxe and hl as of this writing.

[ncannasse]

I'm not able to reproduce on both Win32 and Win64. Could you check again and give me the C stack trace so I know where this comes from?

[shakesoda]

Here's the trace.

    b=b@entry=0x555555772e88, mode64=mode64@entry=0 '\000') at src/jit.c:517
517				ASSERT(0);
(gdb) bt
#0  op (ctx=ctx@entry=0x555555772dd0, o=o@entry=MOV8, 
    a=a@entry=0x555555772ea0, b=b@entry=0x555555772e88, 
    mode64=mode64@entry=0 '\000') at src/jit.c:517
#1  0x000055555555b9b8 in op32 (ctx=ctx@entry=0x555555772dd0, o=o@entry=MOV8, 
    a=a@entry=0x555555772ea0, b=b@entry=0x555555772e88) at src/jit.c:791
#2  0x000055555555c5ca in copy (ctx=ctx@entry=0x555555772dd0, 
    to=to@entry=0x555555772ea0, from=0x555555772e88, size=1) at src/jit.c:1106
#3  0x000055555555c913 in copy_from (ctx=ctx@entry=0x555555772dd0, 
    to=to@entry=0x555555772ea0, from=from@entry=0x55555577e2d0)
    at src/jit.c:1238
#4  0x000055555556178c in hl_jit_function (ctx=ctx@entry=0x555555772dd0, 
    m=m@entry=0x55555577fbd0, f=f@entry=0x55555578c278) at src/jit.c:3021
#5  0x0000555555565aa2 in hl_module_init (m=0x55555577fbd0) at src/module.c:382
#6  0x0000555555564c8b in main (argc=0, argv=0x7fffffffde68) at src/main.c:156

As for Win64, it doesn't happen there for me either. Just Linux.

[20kdc]

I instead get JIT ERROR 0 (jit.c line 935). Ubuntu Eoan Ermine (19.10), HashLink 1.10 (64-bit, built locally), Haxe 4.0.0-rc.5. And it is apparently specific to Linux-targetting versions; the HashLink 1.10 Windows release binary under Wine does not appear to exhibit the issue. (This sounds like memory weirdness.) Notably, this formulation also works and is 'cleaner':

class Bug {
	static function explode(v: hl.UI8): Int {
		return Std.int(v);
	}
	static function main() {
		explode(5);
	}
}

An interesting side note is that the HLC form of main in this case is:

void Bug_main() {
	unsigned char r1;
	int r0;
	r0 = 5;
	r1 = (int)r0;
	r0 = Bug_explode(r1);
	return;
}

I don't know if there's an HL disassembler to confirm if that's a Haxe compiler bug, but I do know that r1 = (int)r0; looks... odd. Regardless, the indeterminate nature of what happens afterwards to me says "memory corruption", so it might be useful to track down what those instructions are.

[Frixuu]

Can confirm this is still the case. (Arch Linux amd64, both Haxe 4.3.3 & nightly, both HL 1.13.0 & master)

Implicit conversion also triggers this:

function foo(a: hl.UI8): Int {
    return a;
}
function main() {
    trace(foo(1));
}

For comparison, the following work just fine:

function foo(a: hl.UI16): Int {
    return a;
}

function foo(a: hl.UI8): Float {
    return a;
}

function foo(a: Int): hl.UI8 {
    return a;
}

function main() {
    final a: hl.UI8 = 1;
    final b: Int = a;
    trace(b);
}

[ncannasse]

Ping @yuxiaomao

Le lun. 26 févr. 2024 à 20:28, Frixuu @.***> a écrit :

Can confirm this is still the case. (Arch Linux amd64, both Haxe 4.3.3 & nightly, both HL 1.13.0 & master https://github.com/HaxeFoundation/hashlink/blob/20df6529c932f7e9ab4e1c528a0321723f2d09ae/src/jit.c#L554 )

Implicit conversion also triggers this:

function foo(a: hl.UI8): Int { return a; }function main() { trace(foo(1)); }

For comparison, the following work just fine:

function foo(a: hl.UI16): Int { return a; }

function foo(a: hl.UI8): Float { return a; }

function foo(a: Int): hl.UI8 { return a; }

function main() { final a: hl.UI8 = 1; final b: Int = a; trace(b); }

— Reply to this email directly, view it on GitHub https://github.com/HaxeFoundation/hashlink/issues/142#issuecomment-1965203562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHZXQHWQKIIZQQ6QBKXRWLYVTV5RAVCNFSM4E53TVV2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWGUZDAMZVGYZA . You are receiving this because you commented.Message ID: @.***>