Open tobil4sk opened 1 year ago
We just had a similar crash on Windows, so looks like it's not specific to Linux:
Command: haxelib [git,utest,https://github.com/haxe-utest/utest,master,--always]
Installing utest from https://github.com/haxe-utest/utest branch: master
Library utest current version is now git
Command exited with -1073741819 in 3s: haxelib [git,utest,https://github.com/haxe-utest/utest,master,--always]
-1073741819 is equivalent to 0xC0000005, which is STATUS_ACCESS_VIOLATION
: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
This sample seems to reproduce the seg fault some of the time, at least on my windows machine:
function main() {
final streamsLock = new sys.thread.Lock();
sys.thread.Thread.create(function() {
Sys.sleep(0.2);
streamsLock.release();
});
sys.thread.Thread.create(function() {
Sys.sleep(0.2);
streamsLock.release();
});
streamsLock.wait();
streamsLock.wait();
}
Ever since haxelib was updated to use threads on neko, it has been segfaulting randomly in github actions. e.g.
I haven't been able to reproduce at all on any local systems, but I did some troubleshooting and I found that the seg fault occurs after the main function is completed, at some point after this call, but before the program closes: https://github.com/HaxeFoundation/neko/blob/master/vm/main.c#L342.
I managed to download the core dump and load it, and it says that the seg fault comes from line 46 here: https://github.com/HaxeFoundation/neko/blob/9076cfa9dfd517da128a54fcabee5abe4129790b/vm/callback.c#L44-L48
I later added a printf here and confirmed that during the segfault, vm is a null pointer. Perhaps there is a finaliser that is getting called after the main function has already finished or something?
Full backtrace
``` Core was generated by `haxelib git utest https://github.com/haxe-utest/utest master --always'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f30d8f14ef6 in neko_val_callEx (vthis=0x7f30d782a000, f=0x7f30d8b4d8a0, args=0x7f30d5e3d7f8, nargs=1, exc=0x0) at /src/vm/callback.c:46 46 /src/vm/callback.c: Bad file descriptor. [Current thread is 1 (LWP 2473)] (gdb) bt #0 0x00007f30d8f14ef6 in neko_val_callEx (vthis=0x7f30d782a000, f=0x7f30d8b4d8a0, args=0x7f30d5e3d7f8, nargs=1, exc=0x0) at /src/vm/callback.c:46 #1 0x00007f30d8f17818 in neko_interp_loop (vm=0x7f30d77e61c0, m=0x7f30d8b4cea0, _acc=139847740806880, _pc=0x7f30d77109b8) at /src/vm/interp.c:708 #2 0x00007f30d8f20e24 in neko_interp (vm=0x7f30d77e61c0, _m=0x7f30d8b4cea0, acc=139847740806880, pc=0x7f30d77109b8) at /src/vm/interp.c:1214 #3 0x00007f30d8f15511 in neko_val_callEx (vthis=0x7f30d914f870Here is the code in haxelib that uses threads: https://github.com/HaxeFoundation/haxelib/blob/4.1.x/src/haxelib/client/Vcs.hx#L162-L177