SigMask has changed, says kj.
IngwiePhoenix opened this issue · 2 comments
Hello there!
I am running into a bit of an annoying issue here... Now, granted, my environment is pretty different and special; I run this on an OpenWrt base, with APK added to have access to development packages, on an arm64 SBC. So I admit, this is a bit odd, but the RockChip RK3588 is very capable.
Now, this is the issue I have:
root@FriendlyWrt /u/laminar# sudo --preserve-env=LAMINAR_HOME,LAMINAR_BIND_HTTP -u laminar /usr/local/sbin/laminard -v
laminar.cpp:560: info: Creating a default context with 6 executors
laminard version 1.3-3-g277a59f1 started
terminate called after throwing an instance of 'kj::ExceptionImpl'
what(): kj/async-unix.c++:561: failed: Signal mask has changed since UnixEventPort was constructed. You are required to ensure that whenever control returns to the event loop, the signal mask is the same as it was when UnixEventPort was created. In non-debug builds, this check is skipped, and this situation may instead lead to unexpected results. In particular, while the system is waiting for I/O events, the signal mask may be reverted to what it was at construction time, ignoring your subsequent changes.; changes = signal #17 (Child process status) was added
fish: Job 1, 'sudo --preserve-env=LAMINAR_H...' terminated by signal SIGABRT (Abort)
root@FriendlyWrt /u/laminar [SIGABRT]# grep -r "sigprocmask" /usb/opt/laminar/src
/usb/opt/laminar/src/leader.cpp: sigprocmask(SIG_UNBLOCK, &mask, nullptr);
OpenWrt runs off of musl, so I took a look there as well, but it appears to not be an issue others have had, so I suppose it's fine? I did have to re-compile Capn Proto myself, because the apk build relied on gLibc++ functions that weren't available in musl.
Do you possibly have a pointer what the issue could be here? I would like to use Laminar as a build-bot to make arm64 images of projects that normally don't have one and that I need myself.
Thank you and kind regards,
Ingwie
UPDATE:
Came across this: https://wiki.musl-libc.org/functional-differences-from-glibc#Signal-mask-and-setjmp/longjmp
However, I have no idea if this applies to forks or not; considering that the only call to sigprocmask is within a forked child...
I have gone down a rabbit hole of trying to statically compile the binaries, and ran into something interesting: Although they are now completely static (I compiled it in a docker container and moved it to the host) the same error still occurs:
root@FriendlyWrt /u/laminar [1]# ./laminard
laminard version 1.3-3-g277a59f1-dirty started
terminate called after throwing an instance of 'kj::ExceptionImpl'
what(): kj/async-unix.c++:567: failed: Signal mask has changed since UnixEventPort was constructed. You are required to ensure that whenever control returns to the event loop, the signal mask is the same as it was when UnixEventPort was created. In non-debug builds, this check is skipped, and this situation may instead lead to unexpected results. In particular, while the system is waiting for I/O events, the signal mask may be reverted to what it was at construction time, ignoring your subsequent changes.; changes = signal #17 (Child process status) was added
fish: Job 1, './laminard' terminated by signal SIGABRT (Abort)
root@FriendlyWrt /u/laminar [SIGABRT]# ldd laminard
/lib/ld-musl-aarch64.so.1: laminard: Not a valid dynamic program
root@FriendlyWrt /u/laminar [1]# ldd laminarc
/lib/ld-musl-aarch64.so.1: laminarc: Not a valid dynamic program
I have completely ran out of ideas, but it's interesting. Do you have any ideas?
The issue has turned out to be a mixture of:
- CMake picking GCC vs. Clang from time to time,
- there somehow being both
libc++andlibstdc++and both ending up in the final linkage tree; the binary used a different one compared to the shared libs it was linked against. Or something of that order, anyway.
I apologize for this non issue; after reinstalling my OS, I got Laminar to work - and build! It's been working nice, but I think I found a bug.