Hide Forgot
Description of problem: Prebuilt Electron apps, notably Slack, segfault on launch on Fedora 29 with glibc 2.28. The issue was introduced by this commit to glibc: https://sourceware.org/git/?p=glibc.git;a=commit;h=b44e0dfbacecd0f84ebfa942e6d6c0153981680e and is also present on Ubuntu, Arch and other distributions. It can be worked around temporarily by reverting the commit to glibc. Version-Release number of selected component (if applicable): 2.28 How reproducible: Always Steps to Reproduce: 1. Install Fedora 29, updated or not 2. Download and install Slack 3.3.3 from https://slack.com/downloads/linux 3. Launch Slack Actual results: Core dump immediately on start Expected results: Slack opens Additional info: I have a COPR here: https://copr.fedorainfracloud.org/coprs/ghjm/glibc/ with glibc builds that revert the problematic commit, which I have been running on my own laptop without issues. Also see: https://github.com/electron/electron/issues/13972 https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1790966
The Electron binaries have been linked by a broken linker. These applications need to bundle an updated Electron framework.
From the point of view of a user, you have perfectly functional applications like Slack and VS Code, then you do an update, and now all your apps are coredumping. Calling this "NOTABUG" is pretty disappointing for these users.
(In reply to Graham Mainwaring from comment #2) > From the point of view of a user, you have perfectly functional applications > like Slack and VS Code, then you do an update, and now all your apps are > coredumping. Calling this "NOTABUG" is pretty disappointing for these users. It is also disappointing to an entirely different set of users if we revert the improvements that lead to the exposing of this lld bug. The Fedora Toolchain Team does the best it can to balance priorities from various user groups. In this case the bundled electron builds with a broken llvm lld need to be fixed. Reverting the SHN_ABS treatment in glibc can have serious consequences for applications built that use SHN_ABS (automatically used by the toolchain) and therefore that is also something we don't want to do since we would just have to undo it again in the next release. The best option overall is to wait for the software vendor to update their release and fix their bugs, or use isolation technology to run the application.