Electron applications all crash upon launch

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

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

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

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

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.

It also affects slack desktop and insync.

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.

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
>
>

@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.

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.

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

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

Dylan, looks like Electron 14+ has the fix.

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

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.

@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

>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);
++ }

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

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.

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

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 .

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

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

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?

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.

@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.

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

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

Running with the --no-sandbox is working.

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

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

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.

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

@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

Great!

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

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?

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.

@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?

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...

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.

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

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

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

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").

"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.

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.".

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.

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

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...

phil dude

File a new bug report.