Open eddsalkield opened 2 years ago
Ahh yes, alpine - I think I remember some others mentioning issues running on musl, might be related to that,... kinda hard to debug with this little info ^^'
I haven't had the time to look further, but I intend to try and create an Alpine package for this project. I'll get back to you with more information as I proceed :)
TLDR: turns out it's a problem with upstream rust that's known about and being worked on. For now, this can be fixed by explicitly specifying no static linking with RUSTFLAGS="-C target-feature=-crt-static" cargo +nightly build --r elease --no-default-features --features=wayland
. Perhaps we could update the documentation for anyone else wanting to link against musl libc?
Further investigation has revealed that there are currently problems in rust when it comes to static/dynamic linking. eww depends on gtk, which on Alpine is dynamically linked with musl libc. However, rustc by default links musl statically with eww, meaning that we have two different versions of musl - one static and the other dynamic. This causes the method at gtk::rt::init
to be initialised to the null pointer, causing a segfault when it's called.
This valgrind output clearly shows what's going on:
==5684== Jump to the invalid address stated on the next line
==5684== at 0x0: ???
==5684== by 0x5E7E72: gtk::rt::init (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x27A677: eww::server::initialize_server (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x265575: eww::main (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x269D62: std::sys_common::backtrace::__rust_begin_short_backtrace (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x1B42B8: _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h3c8bc9ab34e683baE.llvm.8964202568776711341 (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x61266C: std::rt::lang_start_internal (function.rs:259)
==5684== by 0x266AE1: main (in /home/edd/dev/eww/target/release/eww)
==5684== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5684==
==5684==
==5684== Process terminating with default action of signal 11 (SIGSEGV)
==5684== Bad permissions for mapped region at address 0x0
==5684== at 0x0: ???
==5684== by 0x5E7E72: gtk::rt::init (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x27A677: eww::server::initialize_server (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x265575: eww::main (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x269D62: std::sys_common::backtrace::__rust_begin_short_backtrace (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x1B42B8: _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h3c8bc9ab34e683baE.llvm.8964202568776711341 (in /home/edd/dev/eww/target/release/eww)
==5684== by 0x61266C: std::rt::lang_start_internal (function.rs:259)
==5684== by 0x266AE1: main (in /home/edd/dev/eww/target/release/eww)
==5684==
==5684== HEAP SUMMARY:
==5684== in use at exit: 0 bytes in 0 blocks
==5684== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5684==
==5684== All heap blocks were freed -- no leaks are possible
==5684==
==5684== Use --track-origins=yes to see where uninitialised values come from
==5684== For lists of detected and suppressed errors, rerun with: -s
==5684== ERROR SUMMARY: 5007 errors from 65 contexts (suppressed: 0 from 0)
Segmentation fault
More information can be found in this gtk bug, and these rustlang issues.
Perhaps if the documentation is getting updated with this temporary fix, we could also update it to list musl
as a valid alternative to glibc
in the packages list?
That worked for me on void. Thanks!
Checklist before submitting an issue
Describe the bug
On Alpine Linux, the current master branch segfaults when
eww daemon --no-daemonize
is run.Reproducing the issue
Compile
eww
from master on mainline Alpine. Create ~/.config/eww. Runeww daemon --no-daemonize
Additional context