Electron apps segfault on glibc 2.28 (cosmic)

Bug #1790966 reported by Maarten Fonville
212
This bug affects 39 people
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Electron apps (like Atom) give a segfault when trying to start them on Ubuntu Cosmic.
Apparently this is related to a certain commit that is part of glibc 2.28.

Could the workaround as e.g. Arch has implemented also be applied to Ubuntu, otherwise many pre-compiled applications will not work when Cosmic will be released.

For more information, see bug: https://github.com/electron/electron/issues/13972

Tags: patch
Revision history for this message
Maarten Fonville (maarten-fonville) wrote :

Based on the patch of Arch Linux, to at least temporarily work around the Electron ldd bug, because the large impact it has.

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=f2aaaac68876f6959c62ea09dcdda5d441bf4ff7

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Revert-elf-Correct-absolute-SHN_ABS-symbol-run-time.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Maarten Fonville (maarten-fonville) wrote :
Revision history for this message
Matthias Klose (doko) wrote :

I don't think we should work around that. The fix is to rebuild elctron with a fixed linker. Would the BFD linker or gold work?

Changed in glibc (Ubuntu):
status: New → Incomplete
Revision history for this message
Maarten Fonville (maarten-fonville) wrote :

I don't know if the BFD linker or gold would work.

Ofc the fix would be to rebuild all respective Electron apps, but I doubt all (proprietary) apps will already have a new release by October. The fix for Electron was only released end of August.

It is a very unexpected regression, because goal is (and assumed to be true) that glibc ABI doesn't break.

IMHO it is best to make the same choice as Arch, and avoiding breakage, until most Electron apps will have a chance to upgrade their Electron core.

Revision history for this message
Khairul Aizat Kamarudzzaman (fenris) wrote :

thanks @maarten for the patch.

after applying your ppa, all my apps (related to electron such skype, slack & visual studio code) works again as its crashed before this.

thanks again !!!

Revision history for this message
Martin Wimpress  (flexiondotorg) wrote :

This issue affects Electron apps built with Electron <= 2.0.7 and is fixed in Electron 2.0.8.

  * https://github.com/electron/electron/issues/13972

Few Electron applications have made the transition to Electron 2.x, but those that have will need to be rebuilt with Electron >== 2.0.8

Revision history for this message
Maarten Fonville (maarten-fonville) wrote :

For those that use Atom, upcoming release should have the fix: https://github.com/atom/atom/pull/18012

Revision history for this message
Jean-Louis Dupond (dupondje) wrote :

FYI: Slack responded me with:
'We hope to get a fix out for this issue in Slack version 3.3.3. I don't have a release date for that just yet, but it's not far away.'

Revision history for this message
Kai Mast (kai-mast) wrote :

Slack 3.3.3 still crashes for me.

Revision history for this message
Gerardo Perosio (gperosio) wrote :

Same issue. Resolved installing packages from @maarten repo. Thanks @maarten!

Revision history for this message
Huan Zhang (victzhang) wrote :

Slack 3.3.3 crashes with the following backtrace:

#0 0x0000000000dbf060 in ?? ()
#1 0x00007ffff7d83072 in node::http2::Http2Session::Callbacks::Callbacks(bool)
    () from /usr/lib/slack/libnode.so
#2 0x00007ffff7d83135 in ?? () from /usr/lib/slack/libnode.so
#3 0x00007ffff7fe398a in call_init (l=<optimized out>, argc=argc@entry=1,
    argv=argv@entry=0x7fffffffdf68, env=env@entry=0x7fffffffdf78)
    at dl-init.c:72
#4 0x00007ffff7fe3a89 in call_init (env=0x7fffffffdf78, argv=0x7fffffffdf68,
    argc=1, l=<optimized out>) at dl-init.c:30
#5 _dl_init (main_map=0x7ffff7ffe190, argc=1, argv=0x7fffffffdf68,
    env=0x7fffffffdf78) at dl-init.c:119
#6 0x00007ffff7fd40ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#7 0x0000000000000001 in ?? ()
#8 0x00007fffffffe2b3 in ?? ()
#9 0x0000000000000000 in ?? ()

Revision history for this message
Tuomo Sipola (tuomosipola) wrote :

Temporary workaround: Installing the newest version from snap.

Revision history for this message
Eli Schwartz (eschwartz) wrote :

@doko, Arch Linux staff here.

The reason we reverted the glibc commit has nothing to do with rebuilding electron with bfd or gold linkers. lld works fine, and we use it in our distribution electron packages without issue!

The problem is entirely due to people who ship proprietary electron applications containing *old* prebuilt electron binaries provided by the Electron project. Prebuilt binaries are pretty unfortunate in general, and the fact that they're broken just goes to show how utterly right we were to use the system lld when building electron, but, that doesn't help people who use prebuilt packages!

There's a couple solutions to the problem of prebuilt binaries with invalid codegen:

- Rebuild all electron applications so they utilize the correctly linked system electron, including rebuilding the binary node extensions that are proprietary and don't have available source code. Then convince all Ubuntu users to exclusively use these applications from the Ubuntu repositories. Wait, what system electron? Ubuntu doesn't have one. Also, that's a lot of applications to rebuild, and how do you know which ones users need?

- Force all proprietary software using electron, to build their own updates incorporating the new electron 2.0.8 (that is notable because the electron build scripts which use a private clang/llvm/lld toolchain, have updated their toolchain to not use a broken lld revision). Good luck getting that to happen!

- Revert the glibc commit, which means you're certainly no worse off than glibc 2.27 used to be, and which lets binaries in the wild still work, at least for a couple months until more proprietary applications get fixed.

...

I entirely sympathize with the desire to say "prebuilt binaries suck and it's not our fault if they're also broken, maybe if their stuff is broken on Ubuntu they'll be worried enough to fix it pronto".

I'm merely commenting on the options, with the observation that someone with more authority than me chose to use the patch in Arch Linux.

Revision history for this message
mike@papersolve.com (mike-papersolve) wrote :

thanks @maarten !! CrashPlan GUI works now.

Revision history for this message
David Skoland (dskoland) wrote :

@maarten's patch worked for me.

ndstate (ndstate)
Changed in glibc (Ubuntu):
status: Incomplete → Confirmed
status: Confirmed → Incomplete
Revision history for this message
Adam Conrad (adconrad) wrote :

Based on the fact that various upstreams have rebuilt to fix their apps, and also taking into account Carlos and Florian's arguments in the Fedora bug[1], I'm closing this Won't Fix. It's unfortunate, but reverting this wouldn't be a particularly good way forward.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1653832

Changed in glibc (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Ian (superian) wrote :

Some upstreams have, some haven't. CrashPlan is an example of the latter.

Revision history for this message
aM (rydell) wrote :

If it still matters to anyone, I've managed to get Crashplan's desktop app to run, by downloading Electron 2.0.8, extracting libnode.so from the archive, and replacing /usr/local/crashplan/electron/libnode.so with the one from the electron 2.0.8 zip.

My system is Debian, but I imagine that this can work for Ubuntu as well.

(This is of course not in any way supported by Code42 or anyone else)

Revision history for this message
Mark Rich (sir-marky) wrote :

@aM, your solution worked for me too. I now have Crashplan working.

Revision history for this message
Naegling23 (naegling23) wrote :

trying to get crashplan desktop to run. @aM, how do I download electron 2.08? I cant seem to find/figure it out

Revision history for this message
Naegling23 (naegling23) wrote :

figured it out...works!!!!!thank you!!!!

Revision history for this message
Naegling23 (naegling23) wrote :

nevermind, worked once, the app hung up on signing in so I killed it. Stopped working now.

Revision history for this message
Kidd Supreme (kiddsupreme) wrote :

@Naegling23 So I'm running Fedora 29 myself. And just like you, it at first worked, then just stayed there trying to login. Any subsequent attempt to start the program crashed like before. Until I did the following:

sudo chmod 444 libnode.so

Basically, I made the file read-only. At that point, I started the CrashPlanDesktop (after copying a "new" copy of libnode.so) and it worked. Please let me know if this works for you as well.

Revision history for this message
Ventusfahrer (ventusfahrer) wrote :

I ran in the CrashPlanDesktop crash problem after upgrading to Ubuntu 19.04 (18.10 had probably the same problem). electron 2.08 fixes the problem too.
Just to give you a hint to the place where to copy from: https://github.com/electron/electron/releases/tag/v2.0.8.
Pick the right electron-2.0.8-<plattform>.zip, unpack the archive an copy every file in the root directory of the archive to the electron directory of crashplan (in my case /usr/local/crashplan/electron). That's it.

Revision history for this message
Ian (superian) wrote :

Ah ha, from https://support.code42.com/Release_Notes/CrashPlan_for_Small_Business_release_notes for the recently released version of 7.0.0 for CrashPlan..

"Updates third-party library Electron to version 2.0.8. This resolves an issue in which the Code42 app did not run on some Linux distributions."

About time...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.