electron: Prebuilt Electron binaries segfault at startup on Arch Linux with glibc 2.28

For a workaround for ubuntu 18.10 users, see this comment. I can confirm it works.

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1790966/comments/3

Another workaround that worked for me in 18.10 was to simply replace libnode.so with a newer version. For slack replace /usr/lib/slack/libnode.so with e.g libnode.so found in https://github.com/electron/electron/releases/download/v2.0.12/electron-v2.0.12-linux-x64.zip

Edit: Celebrated too soon. Slack becomes unstable and crashes and restarts every now and then with the updated lib.

For Slack users who replaced libnode.so from somewhere else (and got the app running again) but still get the occasional crash, disable your notification sound for now.

It seems if Slack tries to play the notification sound for a new message, it simply restarts instead of ever getting around to playing the clip.

@pcc on #llvm IRC found the exact revision that fixed it: https://github.com/llvm-project/lld/commit/1adba6d5d2f5f51d0719e81f71461437ecc1bd59

Electron apps including Slack are also broken on Fedora 29 for the same reason. I built a glibc with @mfonville’s patch, which solves the problem for me. This build is available here: https://copr.fedorainfracloud.org/coprs/ghjm/glibc/. You can install the updated glibc using dnf copr enable ghjm/glibc && dnf update glibc (and then probably reboot).

slack segfaults on 18.10

I hope this comment doesn’t derail the conversation into a stream of broken apps. If it does, I apologize.

So for me, this issue breaks the Slack desktop app on Ubuntu cosmic. For the same issue with Atom, an upgrade to the latest beta resolved it, so I assume I just need to wait for the Slack team to roll out a new version?

For reference, users of Slack should upgrade to version 3.3.7 released earlier this week, which has this fix: https://slack.com/release-notes/linux

I did not, since I use a pre-built version of Atom.

So I went the other way around, and compiled my own glibc with Arch Linux’s patch for Ubuntu Cosmic, and that works well: https://launchpad.net/~maarten-fonville/+archive/ubuntu/ppa/

@faultylee Yes, but it’s a temporary workaround expressly for this issue, not a permanent fix. The breaking change was identified and reverted in a number of distros, but will be restored once electron is using the updated version of LDD (See @K900’s comments above)

See https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=f2aaaac68876f6959c62ea09dcdda5d441bf4ff7 for the comment from the Arch devs

So yeah, it’s definitely a toolchain issue, more specifically a linker issue. Simply replacing vendor/llvm-build/Release+Asserts/bin/lld with a symlink to system lld (version 6.0.1) results in a functional build. I’m guessing it’s a linker bug, so glibc is correct in barfing here. Now to figure out where the Debian sysroot comes from…

The electron package from the Arch Linux community repository was actually built using glibc 2.27, nice try. 😉 (glibc tries pretty hard to maintain ABI compatibility, you should never need to rebuild software in order to work with newer glibc – the fact that this breaks indicates either a glibc bug or a something in the software stack that depends on private details of glibc when it shouldn’t.)

$ bsdtar -xOf /var/cache/pacman/pkg/electron-2.0.6-1-x86_64.pkg.tar.xz .BUILDINFO| grep glibc
installed = glibc-2.27-3-x86_64

So, it’s entirely likely that rebuilding it on Arch Linux with glibc 2.28 would have the same issues, and that the issue lies in the build process. For the record, our package is built using https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/electron and you can see various patches we apply in order to use system dependencies, in the same directory of the git repository as the PKGBUILD file.

It’s literally in the release notes for Electron 2.0.8, that this bug has been fixed (by https://github.com/electron/electron/pull/13988 to be precise).

It was an electron bug, and now it is a bug in any application that has not updated their vendored Electron copies. At this point, the Electron developers have done everything they could in order to fix it.

The only other thing they could do, is to redesign the entire Electron ecosystem to use global, system electron installations by default, which would allow this to be fixed once and applied everywhere. But this is rather out of scope of the issue.

Good news: the tests pass with an updated lld, and the resulting libnode.so isn’t horribly bugged.