Electron applications all crash upon launch

[Erich Eickmeyer]

Just a few weeks ago, I noticed the .deb version of Visual Studio Code crashing upon launch. I also noticed Element (matrix client) also would crash. The only thing these applications have in common is electron. I was hoping this would get noticed by someone and that the issue would be figured out, but I guess that person had to be me.

Erroneously-filed bug 1943568 exhibits the same issues. Experimenting with Visual Studio Code provided this:

[347381:0921/133026.728654:ERROR:proxy_config_service_linux.cc(608)] inotify_init failed: Too many open files (24)
[347419:0921/133026.764752:ERROR:file_path_watcher_linux.cc(326)] inotify_init() failed: Too many open files (24)
[main 2021-09-21T20:30:26.930Z] update#setState idle
[347381:0921/133027.009472:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347381:0921/133027.323205:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347381:0921/133027.690827:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347490:0921/133027.728195:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is swiftshader
[347381:0921/133027.879310:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347495:0921/133027.894439:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is swiftshader
[347381:0921/133028.049455:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347499:0921/133028.063977:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is swiftshader
[347381:0921/133028.216114:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347511:0921/133028.222585:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is disabled
[347381:0921/133028.384052:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347515:0921/133028.442903:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is disabled
[347381:0921/133028.596590:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347519:0921/133028.602088:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is disabled
[347381:0921/133028.749373:ERROR:gpu_process_host.cc(1007)] GPU process exited unexpectedly: exit_code=159
[347381:0921/133028.749401:FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.
Server response:
Server response:
Illegal instruction (core dumped)

Atom provided this:

[347834:0921/133121.907198:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye.

Unexpected crash report id length
Failed to get crash dump id.
Report Id:

Unexpected crash report id length
Failed to get crash dump id.
Report Id:
Illegal instruction (core dumped)

When either application was provided "--no-sandbox" at the command line, they would run normally. However, Element does not pass that via command line, so I was unable to use the workaround for that.

Upon investigating the runtime dependencies for Element, Atom, and VSCode, the one thing they had in common was libgtk-3-0, and the date of 2021-09-03 for publishing coincides with the time in which these errors started to appear.

Another workaround, other than the "--no-sandbox" usage, is to use the snap version of the apps if available, or flatpak. These provide their own versions of these dependencies, which tells me these .deb-based applications are affected by libgtk-3-0.

Granted, those applications are not in the Ubuntu repository, however, many people (including myself) rely on those to function correctly. It would be very bad if Electron apps failed to function when 21.10 is released.

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: libgtk-3-0 3.24.30-1ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-16.16-lowlatency 5.13.13
Uname: Linux 5.13.0-16-lowlatency x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu69
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Tue Sep 21 13:25:17 2021
InstallationDate: Installed on 2021-03-20 (184 days ago)
InstallationMedia: Ubuntu-Studio 21.04 "Hirsute Hippo" - Alpha amd64 (20210320)
SourcePackage: gtk+3.0
UpgradeStatus: Upgraded to impish on 2021-06-13 (100 days ago)

[TJ (tj)]

I suspect these may be related:

https://github.com/electron/electron/pull/30893 "fix: crash when launching app with systemd v249"

https://github.com/microsoft/vscode/issues/132609 "Electron 14+ required? Potential systemd 249 / nVidia issue"

Electron patch backported from Chromium:

https://github.com/electron/electron/commit/1d531f29eeb8392195262bea038abed75fb51b8c

https://bugs.chromium.org/p/chromium/issues/detail?id=1221442

Also, have you considered this could be caused by a recent Electron update that has made its way into these applications?

https://www.electronjs.org/releases/stable

Electron Sandboxing Overview

https://www.electronjs.org/docs/tutorial/sandbox

[Sebastien Bacher (seb128)]

It's due to the new glibc, confirmed using vscode

download and install using https://code.visualstudio.com/sha/download?build=stable&os=linux-deb-x64

$ code

on an hirsute machine it works correctly, add an impish source and upgrade libc6 and it fails to start with the error reported

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1944468

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dylan Borg (borgdylan)]

As far as my testing went, this affects VS COde, Azure Data Studio, MS Teams and Skype. Using --no-sandbox or even --disable-gpu-sandbox allows all these to launch.

[Hadrien Mary (hadim)]

It also affects slack desktop and insync.

[Michael Hudson-Doyle (mwhudson)]

So I am having a bit of a hard time debugging this. My conclusions so far:

1) it's a real problem
2) it's related to the new clone3 syscall

Do electron apps use seccomp by default? It seems code has some way to turn this off automagically but if I run code --enable-sandbox it reliably crashes. Haven't been able to gdb to the crashing point yet though.

[Michael Hudson-Doyle (mwhudson)]

Oh looks like these electron apps were built with a chromium that lacks
this commit
https://chromium.googlesource.com/chromium/src/+/218438259dd795456f0a48f67cbe5b4e520db88b
- which was only 4 months ago. And Chromium's sandbox defaults to crashing
on unknown syscalls. So I guess we're back to the "do we disable clone3 for
impish" question.

On Thu, 23 Sep 2021, 16:20 Michael Hudson-Doyle, <email address hidden>
wrote:

> So I am having a bit of a hard time debugging this. My conclusions so
> far:
>
> 1) it's a real problem
> 2) it's related to the new clone3 syscall
>
> Do electron apps use seccomp by default? It seems code has some way to
> turn this off automagically but if I run code --enable-sandbox it
> reliably crashes. Haven't been able to gdb to the crashing point yet
> though.
>
> --
> You received this bug notification because you are a member of Ubuntu
> Toolchain Hackers, which is subscribed to glibc in Ubuntu.
> https://bugs.launchpad.net/bugs/1944468
>
> Title:
> Electron applications all crash upon launch
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468/+subscriptions
>
>

[Dylan Borg (borgdylan)]

@mwhudson WHixh stable versions of electron incorporate that commit? It would be useful to tell that to application maitnainers so they could update their electron dependency.

[Michael Hudson-Doyle (mwhudson)]

That's a good question and I don't know off the top of my head. I'll try to
find out tomorrow unless someone can weigh in with some clues.

[Michael Hudson-Doyle (mwhudson)]

It also looks a bit as if crashing on an unknown syscall is unintended. So
there might be more than one bug.

[Rik Mills (rikmills)]

On 23/09/2021 05:12, Michael Hudson-Doyle wrote:
> 1) it's a real problem
> 2) it's related to the new clone3 syscall
>
> Do electron apps use seccomp by default? It seems code has some way to
> turn this off automagically but if I run code --enable-sandbox it
> reliably crashes. Haven't been able to gdb to the crashing point yet
> though.

Ah, the makes sense. We had a similar problem with clone3 change causing
QtWebengine (Qt chromium build) apps to crash on start. LP: #1939993

[Michael Hudson-Doyle (mwhudson)]

Dylan, looks like Electron 14+ has the fix.

[Deepak Mohan (deepak1556)]

FYI, the fix is now being backported to Electron 13 and also Electron 12 https://github.com/electron/electron/pull/31091

[Michael Hudson-Doyle (mwhudson)]

Ah, glad to hear the fix is making it's way back. I still wonder if disabling clone3 for impish release is the pragmatic thing to do, I don't know if vscode, slack, skype etc etc are going to get an update in the next 4 weeks.

[Sebastien Bacher (seb128)]

@Michael, it's pretty clear than some electron based applications aren't going to be updated before impish is out, reverting is what makes the most sense probably there

[Rik Mills (rikmills)]

>Ah, glad to hear the fix is making it's way back. I still wonder if disabling clone3 for impish release is the pragmatic thing to do, I
>don't know if vscode, slack, skype etc etc are going to get an update in the next 4 weeks.

Would reverting re-break QtWebEngine based apps fixed in LP: #1939993 ?

EDIT: perhaps not as the patch fixing is 'if' guarded:

++ // clone3 takes a pointer argument which we cannot examine, so return ENOSYS
++ // to force the libc to use clone. See https://crbug.com/1213452.
++ if (sysno == __NR_clone3) {
++ return Error(ENOSYS);
++ }

[Francois Thirioux (fthx)]

Related:
https://github.com/rstudio/rstudio/issues/9854

[Michael Hudson-Doyle (mwhudson)]

I've made a patched glibc package with clone3 disabled at https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=glibc, would be interesting to hear if it helps.

[Dylan Borg (borgdylan)]

If I had to install from the PPA, would I have a clean upgrade path if the patch gets adopted in the main archives?

[Norbert (nrbrtx)]

Brackets installed by using the following commands

```
cd ~/Downloads
wget https://github.com/adobe/brackets/releases/download/release-1.14.1/Brackets.Release.1.14.1.64-bit.deb

dpkg-deb -R ./Brackets.Release.1.14.1.64-bit.deb Brackets
sed -i 's/libcurl3/libcurl3 | libcurl4/' Brackets/DEBIAN/control
dpkg-deb -b Brackets Brackets-fixed.deb
sudo apt install -f ./Brackets-fixed.deb

```

is also affected by this bug. Ref: https://askubuntu.com/q/1364480/66509 .

[Emily Loebl (mloebl)]

@mwhudson can confirm using your ppa version, Slack and other electron apps started working again.

[Mike Adams (mikethebos)]

@mwhudson I can also confirm using your ppa version. Plus, apps bundled with Qt begin to work again.

[Marcos Alano (mhalano)]

I installed your glibc packages and 1Password start to work again. However I had problems with Widevine in Firefox (.deb package).It was crashing when I used GMP sandboxing. If I disabled temporarily the sandbox Netflix and other services worked again. Someone could test to see if it's a general bug related to glibc or I'm just the (not) lucky one?

[Ghanshyam (gparvind)]

glibc patch didn't help with vscode and ms teams. both only work with --no-sandbox
update: I might not have installed the glibc patch correctly. installed it from https://launchpad.net/~mwhudson/+archive/ubuntu/devirt now vscode and ms teams launch without --no-sandbox option as well.

[Marcos Alano (mhalano)]

@mwhudson Without your glibc the Electron apps I tested, 1Password and MS Teams, open up a blank screen. When I install your glibc than works as expected. About the Widevine I will look for another bug report or create one. With or without your glibc the Widevine crashes. The only way to avoid it is to execute Firefox from terminal so it gets the environment variable to stop using the sandbox.

[Mike Adams (mikethebos)]

MS Teams (.deb) worked for me with the glibc patch.

[Bill (franksmcb) (franksmcb)]

I am seeing the same issue with the newest Discord .deb.

Running with the --no-sandbox is working.

[Erich Eickmeyer (eeickmeyer)]

I can confirm @mwhudson's glibc build from https://launchpad.net/~mwhudson/+archive/ubuntu/devirt fixed the issue for me as well.

[Fabio Rotondo (fabio-rotondo)]

I can confirm @mwhudson's glibc build from https://launchpad.net/~mwhudson/+archive/ubuntu/devirt fixed the issue for me with VSCode.

[Sergei (olosegres)]

I confirm that all electron apps (build with electron version < 14) does not open devTools. So, for some applications this is critical (for example it is one of main function of react-native-debugger).

Confirm that libc6 patch from https://launchpad.net/~mwhudson/+archive/ubuntu/devirt fixes the problem.

[Mike Adams (mikethebos)]

@mwhudson Since many applications have not updated to the patched electron and qt distributions, should this glibc patch be integrated into impish?

[Erich Eickmeyer (eeickmeyer)]

@mikethebos1 You'll see that the fix is in the proposed pocket[1], awaiting migration. However, since glibc pretty much touches *everything* it has a lot of hoops to jump through with autopkgtests before it can migrate to the release pocket[2]. Rest assured, it's work-in-progress at this point with a lot of automated systems.

[1] https://launchpad.net/ubuntu/+source/glibc
[2] https://people.canonical.com/~ubuntu-archive/proposed-migration/impish/update_excuses.html#glibc

[Mike Adams (mikethebos)]

Great!

[Launchpad Janitor (janitor)]

This bug was fixed in the package glibc - 2.34-0ubuntu3

---------------
glibc (2.34-0ubuntu3) impish; urgency=medium

  * d/patches/git-updates.diff: Update from release/2.34/master branch.
    - d/patches/ubuntu/Fix-close_range-closefrom-tests.patch,
      d/patches/ubuntu/fix-iconvconfig-directory.diff: removed as now
      upstream.
  * d/patches/ubuntu/disable-clone3.patch: Disable use of clone3 syscall
    to give Electron apps more time to get rebuilt. (LP: #1944468)

 -- Michael Hudson-Doyle <email address hidden> Tue, 28 Sep 2021 14:38:09 +1300

[Martin Liska (mliska)]

Note disabling clone3 syscall in glibc breaks all containers (using docker) running on Ubuntu that are linked against glibc that does support the syscall.

One example is opensuse/tumbleweed and one can see the failure e.g. at GitHub Actions:
https://github.com/davidmalcolm/texi2rst/runs/3918101058?check_suite_focus=true

Can you please enable clone3 any time soon?

[Michael Hudson-Doyle (mwhudson)]

I think you have things a bit backwards there. You are using a Docker image that has clone3 enabled in its libc and the container runtime in the environment the github action is running in is the thing that is not supporting the clone3 syscall. Whether the glibc in Ubuntu 21.10 issues the clone3 syscall or not is entirely irrelevant to this.

What is relevant to your issue is where docker get their container runtime from. I've looked this up in the past but I can't remember the details now. I don't think it's the version that's in the Ubuntu 20.04 archives though (the update will the needed fix is in proposed now and will hopefully migrate to updates soon, which will help a lot of people facing this issue -- but not afaict github actions). Basically you need to watch https://github.com/actions/virtual-environments/issues/3812 I think.

[NOAH BACON (t000)]

@mwhudson

A number of open source projects I use haven't had the capacity to patch their releases with the fix for Electron :( Would you be willing to add your patched version of glibc that disables clone3 back to your repository?

[Michael Hudson-Doyle (mwhudson)]

Noah,

I'm not completely opposed to that but I would rather not. Which projects are affected? Can we put some pressure on them to rebuild? It'll be well over 6 months from this becoming an issue to the release of 22.04 and all that's required is a rebuild with the latest point release of whatever electron series a project uses...

[Florian Weimer (fweimer)]

Doesn't Electron need regular security updates for its browser engine? If true, these projects really need to figure out how to rebuild regularly against current Electron versions.

[Francois Thirioux (fthx)]

FYI RStudio is currently affected again, Ubuntu Jammy dev.
https://github.com/rstudio/rstudio/issues/9854

[Dylan Borg (borgdylan)]

Is this taken care of on 22.04 (jammy)? Some electron projects may not have a new enough electron version.

[Erich Eickmeyer (eeickmeyer)]

If it wasn't taken care of in Jammy, a new bug report would've been filed. Let's stop necro-bumping closed bugs.

[Michael Hudson-Doyle (mwhudson)]

At this point I expect jammy glibc to use the clone3 syscall. The only application I've had complaints about is rstudio and they have a plan (which is roughly speaking "start using Election").

[Ian (superian)]

"Expect? Oh yes, expect.." - Marvin, in The Hitch-hiker's Guide to the Galaxy, fit the 7th.

Two Electron-based programs I use that don't work with Jammy are BalenaEtcher (only works if run as root) and Code42 (the desktop application for Crashplan for Small Businesses online backup, which specifically refuses to run as root).

As both are very definitely third party projects, this would seem to be the place to mention that here: it's no longer "all" applications crashing on launch, just "some".

I will try the PPA and see what happens.

[JC (jlilot)]

I'm on 22.04 jammy (clean install) and code42 (Crashplan SMB 8.8.4, just installed) is crashing on start with "6272:0508/105039.170247:FATAL:gpu_data_manager_impl_private.cc(445)] GPU process isn't usable. Goodbye.".

[Erich Eickmeyer (eeickmeyer)]

At this point, since this bug is so old, it's pretty much on the developers of the individual electron apps to get their electron versions up-to-date. The electron version that fixes the problem is ancient now. This is no longer Ubuntu or anybody else's fault, so I think necro-bumping this bug needs to stop.

==== ===== ===== ====

[phil dude (phil-dude-1234)]

ERROR:proxy_config_service_linux.cc(614)] inotify_init failed: Too many open files (24)

This for Microsoft StorageExplorer on Ubuntu 22.04!

Not so old...

[Erich Eickmeyer (eeickmeyer)]

phil dude

File a new bug report.