Under a fresh musl system using libffi-3.2.1, things dependent on using libffi's closures system segfault at runtime. While unclear on what exactly breaks internally, I can confirm this specific feature is at fault. An example easily reproducible: - Have a standard/hardened musl install using libffi 3.2.1 - emerge any GTK app using Python bindings (tested: gajim, meld, virt-manager) - Attempt to run A hint over the cause of this issue can be found using gdb. With file set as your favorite python interpreter, and `run /path/to/gajim` (for example) here, a similar backtrace can be reproduced: #1 [..] in gtk_builder_connect_signals_full () at /usr/lib/libgtk-3.so.0 #2 [..] in ffi_call_unix64 () at /usr/lib/libffi.so.6 #3 [..] in ffi_call () at /usr/lib/libffi.so.6 The trace of ffi related -> gtk -> eventual segfault is consistent. A discussion on Alpine's issue tracker over this bug (see: https://gitlab.alpinelinux.org/alpine/aports/issues/4275) found that GCC doesn't define the macro gnu_linux on musl-based systems; instead just having linux. To sum that up, a patch to change "__gnu_linux__" -> "__linux__" (https://gitlab.alpinelinux.org/alpine/aports/blob/0b8e29b1ee209e4f27e6994c49ecedc053954bf6/main/libffi/gnu-linux-define.patch) solves the issue of faulty closures on libffi for musl-based systems. I do not have ownership over the applied patch, so I won't attach. With regards to the future of this bug: Upstream, libffi appears to only use "__linux__" for 3.3. https://github.com/libffi/libffi/commit/e169ba2b83c780058fe626856cfdb5903a85cb97, for example, solves this bug.
> To sum that up, a patch to change "__gnu_linux__" -> "__linux__" > (https://gitlab.alpinelinux.org/alpine/aports/blob/ > 0b8e29b1ee209e4f27e6994c49ecedc053954bf6/main/libffi/gnu-linux-define.patch) > solves the issue of faulty closures on libffi for musl-based systems. I do > not have ownership over the applied patch, so I won't attach. > > With regards to the future of this bug: > Upstream, libffi appears to only use "__linux__" for 3.3. > https://github.com/libffi/libffi/commit/ > e169ba2b83c780058fe626856cfdb5903a85cb97, for example, solves this bug. It's an upstream fix included in libffi-3.3-rc0 and is in gentoo's tree. Does that version work for you?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cd14f3d80746f350e6ffd103cb1f4629c625f2f commit 8cd14f3d80746f350e6ffd103cb1f4629c625f2f Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-09-19 07:29:10 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-09-19 07:29:50 +0000 dev-libs/libffi: backport emutramp fix to 3.2.1, bug #694916 Reported-by: spotlight@joscomputing.space Bug: https://bugs.gentoo.org/694916 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> .../libffi/files/libffi-3.2.1-musl-emutramp.patch | 31 ++++++++++ dev-libs/libffi/libffi-3.2.1-r3.ebuild | 70 ++++++++++++++++++++++ 2 files changed, 101 insertions(+)
(In reply to Sergei Trofimovich from comment #1) > It's an upstream fix included in libffi-3.3-rc0 and is in gentoo's tree. > Does that version work for you? Tried in chroots - can confirm that both 3.2.1-r3 and 3.3_rc0 resolve this issue, thank you!
Thank you for the test! Let's close this bug and stabilize 3.3_rc0 in bug #694978. If it goes bad e can fall back to 3.2.1-r3 stabilization.
