Kirill A. Korinsky

@LeeTibbert, thanks for reply. On Sun, 24 Mar 2024 16:04:55 +0100, LeeTibbert wrote: > > I am guessing that the operating system is OpenBSD? 64bit? > Yes, it is 64bit...

On Sun, 24 Mar 2024 17:34:49 +0100, Wojciech Mazur wrote: > > Have you maybe observed it also on 0.5.0-RC1? In the RC2 we've added https://github.com/scala-native/scala-native/pull/3827 which retries the `read`...

And I have a pice of strange news. I have achieved the same deadlock without scaltests: ``` Program received signal SIGINT, Interrupt. [Switching to thread 602537] kevent () at /tmp/-:2...

@WojciechMazur I can reproduce the deadlock by using scalanative from a06f46dcb9c5aa2cbb52aff298bd551f71dcfbe2, but now I do have only one thread left: ``` Thread 1 (thread 483794): #0 _thread_sys_recvfrom () at /tmp/-:2...

I've tried to revert https://github.com/scala-native/scala-native/pull/3827 and deadlock still here.

Interesting observation with: ``` .nativeSettings(nativeConfig ~= { c => import scala.scalanative.build._ c.withMode(Mode.releaseFast) }) ``` deadlock is quite difficult to reproduce in my small test case, but without this block, each...

Extracted somehow related issue to dedicated ticket: https://github.com/scala-native/scala-native/issues/3859

Future investigation. From `ktrace`/`kdump` point of view I see the last syscalls: ``` 97560 cryptosystem-test 0.000026 RET thrkill 0 97560 cryptosystem-test 0.000006 CALL sigprocmask(SIG_UNBLOCK,0) 97560 cryptosystem-test 0.000003 RET sigprocmask 0x40004...

@WojciechMazur I uses default settings and only switched `releaseFast`. Yes, this application crashes with all GCs which includes `none`. Anyway, I still do not roll out possibility that my code...

I finish to rewriting my code to be thread safe and multithreading ready. Now it fails inside some scala level allocation. So, I almsot 100% sure that it isn't C-level,...