Crash on Linux on Start

[drom]

Prerequisites

• [X] Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

start Atom

Steps to Reproduce

1. open terminal
2. atom

Expected behavior:

Atom starts

Actual behavior:

drom@linux-sydi:~> /usr/bin/atom: line 190: 16684 Illegal instruction     (core dumped) nohup "$ATOM_PATH" --executed-from="$(pwd)" --pid=$$ "$@" > "$ATOM_HOME/nohup.out" 2>&1
[16684:0924/230352.078726:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye.
--2021-09-24 23:03:52--  https://atom.io/crash_reports
Resolving atom.io (atom.io)... 18.205.222.128, 54.161.241.46, 52.202.168.65, ...
Connecting to atom.io (atom.io)|18.205.222.128|:443... connected.
HTTP request sent, awaiting response... 204 No Content
2021-09-24 23:03:53 (0.00 B/s) - ‘/dev/fd/4’ saved [0]


Unexpected crash report id length
Failed to get crash dump id.
Report Id: 
--2021-09-24 23:03:53--  https://atom.io/crash_reports
Resolving atom.io (atom.io)... 18.205.222.128, 54.161.241.46, 52.202.168.65, ...
Connecting to atom.io (atom.io)|18.205.222.128|:443... connected.
HTTP request sent, awaiting response... 204 No Content
2021-09-24 23:03:54 (0.00 B/s) - ‘/dev/fd/4’ saved [0]


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

Reproduces how often:

every time

Versions

Atom    : 1.58.0
Electron: 9.4.4
Chrome  : 83.0.4103.122
Node    : 12.14.1

Additional Information

uname -a

Linux linux-sydi 5.14.5-1-default #1 SMP Thu Sep 16 12:39:52 UTC 2021 (fdb6afd) x86_64 x86_64 x86_64 GNU/Linux

ldd --version ldd

ldd (GNU libc) 2.34
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

[drom]

Maybe related to https://github.com/electron/electron/issues/31113

[drom]

Workaround: atom --no-sandbox

[DeeDeeG]

After browsing https://github.com/microsoft/vscode/issues/133593, I can understand what was going on here.

This had to do with a glibc update. (bug: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468) Something to do with introducing a new syscall, clone3, which Chromium was incompatible with. (bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1244383) Electron's browser-y bits are from Chromium, so Electron was affected as well.

This is patched in Chromium 93 or newer. (Electron 14 shipped with Chromium 93. So Electron 14 and newer natively have the fix.) The fix has been back-ported to Electron 13 as well: https://github.com/electron/electron/pull/31091 (in Electron 13.5.0 and newer 13.x.)

Also: Ubuntu 12.10's glibc has been patched to disable the clone3 syscall, meaning even older versions of Electron should work now, at least on Ubuntu 12.10. (Maybe other Linux distros with glibc 2.34 or newer will do the same, disable clone3 for now, to keep compatibility with older Electron apps?)

For a fuller and more future-proof fix, Atom should eventually upgrade to Electron 13 or newer. (It feels pretty likely that distributions won't keep the clone3 syscall disabled forever just to support older, non-updated Electron apps.)

[thommierother]

This issue originally was triggered from a glibc upgrade and hits a number of electron-based apps, including element-desktop (matrix), vscode, ms teams, Discord - especially in combination with nvidia graphics. Most have already upgraded their embedded electron codebase and atom should do the same. Right now, the workaround switch is

atom --no-sandbox

See https://bugzilla.suse.com/show_bug.cgi?id=1191012 for reference

[mattbit]

In my case, I can run atom with atom --in-process-gpu. Maybe this is a better solution than disabling the sandbox?

[antonellocaroli]

I have the same error after updating the system, I use Gentoo linux.

gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye.
--2021-11-18 05:13:12--  https://atom.io/crash_reports

atom --in-process-gpu seems to work

[weather-tracker]

i was getting that i unistalled it from the gui packed manager and installed it with apt https://flight-manual.atom.io/getting-started/sections/installing-atom/#installing-atom-on-linux then restart computer i can launch atom with atom-nightly and get no errors from terminal

[Pysis868]

Now that I'm trying atom-nightly --in-process-gpu 1.61 and removed the bad document reference it was trying to open, it seems to be working for me now too.... Works with Atom 1.59 too. https://github.com/atom/atom/issues/23167#issuecomment-999113262

[AlexWayfer]

It happens for me after such Arch Linux updates (cut out) :

[2022-02-16T10:53:36+0300] [ALPM] upgraded linux (5.16.8.arch1-1 -> 5.16.9.arch1-1)
[2022-02-16T10:53:38+0300] [ALPM] upgraded nvidia (510.47.03-4 -> 510.54-1)
[2022-02-16T10:53:38+0300] [ALPM] upgraded nodejs (17.3.0-1 -> 17.3.1-1)
[2022-02-16T10:53:38+0300] [ALPM] upgraded npm (8.4.1-1 -> 8.5.0-1)

--in-process-gpu helped.

[yochaigal]

Happening to me in Arch Linux as well. Both --in-process-gpu and --no-sandbox

Allow it to open.

[dhouck]

Yeah, Arch Linux updated glibc a few days ago after months of not. As far as I can tell, Atom is one of four applications there to use a version of Electron before 13.

Iʼm having issues with --in-process-gpu where it will no longer recognize paths provided on the command line, which the same version of atom did before the glibc upgrade. The --no-sandbox option does not have this issue.

[dhouck]

Looking into that with strace, it looks like the --in-process-gpu version never even attempts to read the file (no syscalls mention it except execves passing the same parameters), while the same strace command with --no-sandbox shows a bunch of stat, open, and inotify calls.

[vuxeim]

After updating my Artix linux I was getting that same error on every atom launch. I confirm both --no-sandbox and --in-process-gpu allows it to work.

[GeorgeZack]

After updating my Artix linux I was getting that same error on every atom launch. I confirm both --no-sandbox and --in-process-gpu allows it to work.

Same for me. I uninstalled both Atom and Teams thinking they were broken, but this explains it. Atom works with either options included.

[atongsa]

os: arch linux

atom --in-process-gpu really save my life

[puzzle9]

/usr/share/applications/atom.desktop

[Desktop Entry]
Name=Atom
Comment=A hackable text editor for the 21st Century
GenericName=Text Editor
Exec=env ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false /usr/bin/atom %F --no-sandbox
Icon=atom
Type=Application
StartupNotify=true
Categories=GNOME;GTK;Utility;TextEditor;Development;
MimeType=text/plain;
StartupWMClass=atom

[alerque]

See my comment on #23608, I think this is probably a duplicate issue and both can be closed.

[genygilles]

Also started facing this issue with Ubuntu MATE 22.04 fresh install, atom 1.60 stable

[hakro]

Facing this issue as well on Pop!_OS 22.04. Atom 1.60.0 starts for a couple of seconds, and I can see its window, but then it crashes and vanishes.

Here are the logs :

-> Atom/atom 
[39308:0503/191212.403045: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)

-> uname -a
Linux pop-os 5.16.19-76051619-generic #202204081339~1649696161~22.04~091f44b SMP PREEMPT Mon Apr 11 17 x86_64 x86_64 x86_64 GNU/Linux

Other Electron apps, like Postman, seem to be working fine.

Also Atom/atom --no-sandbox worked fine.

[ghost]

Security Vulnerability

Workaround: atom --no-sandbox

Be advised: using --no-sandbox disables the electron sandbox, and could leave you vulnerable to attacks when installing outdated/unverified packages.

https://github.com/electron/electron/issues/15760

Read more above to find info about the electron sandbox.

---

Related Issues

• #25440
• #25098
• #23493
• #23362
• #23259
• #23608

Potential solution might lie with a later issue of Electron.

https://github.com/Doccrazy/stash-electron/issues/13

---

Verification

https://github.com/atom/atom/issues/23608#issuecomment-1092104266

"I believe this is/was an Electron issue. Since the report is on Atom 1.58.0 / Electron 9 and the current Arch packaging is 1.61.0beta0 / Electron 11 and I cannot reproduce this[...]"

[blueglyph]

Security Vulnerability

Workaround: atom --no-sandbox

Be advised: using --no-sandbox disables the electron sandbox, and could leave you vulnerable to attacks when installing outdated/unverified packages.

electron/electron#15760

Thanks for the heads-up. I'll switch to another editor and re-evaluate later, this is apparently an old problem so it could still take a while.

[hermidalc]

Yeah, Arch Linux updated glibc a few days ago after months of not. As far as I can tell, Atom is one of four applications there to use a version of Electron before 13.

Iʼm having issues with --in-process-gpu where it will no longer recognize paths provided on the command line, which the same version of atom did before the glibc upgrade. The --no-sandbox option does not have this issue.

Or this new issue with Atom on Fedora 36 which forces you to use --no-sandbox:

In Fedora 35 --no-sandbox or --in-process-gpu both worked and solved the editor start crash problem. But now with Fedora 36 using --in-process-gpu the app starts but it crashes when editing settings and clicking on a setting with a drop-down menu... the menu won't show any items and then a second later the entire editor will crash. It doesn't crash every time you click on a setting drop-down but after a couple tries it will crash. When I changed startup to --no-sandbox it doesn't crash when displaying settings drop-down menus.

[ghost]

Atom seems to have become abandonware at this point. Despite efforts by Github to avoid this, the acquisition by Microsoft seems to have led to Atom's silent demise. I've done a bit of looking into this repo and have discovered that there are no strong efforts to update atom, nor are there any experienced maintainers assigned to the project. Given that Atom is reliant upon several now-ancient node packages, the CI pipeline failures, the lack of experienced maintainers, etc. I, personally, would recommend people cease using Atom in favor of a modern editor such as https://github.com/VSCodium/vscodium

[AlexWayfer]

@raer0 yes, I agree with you. But I don't like VS Code, there are even no such features like "change font size for UI". And I love Atom. And it's difficult choice. I'm upset that there is no active maintainers from the community to keep it alive.

[hermidalc]

@raer0 yes, I agree with you. But I don't like VS Code, there are even no such features like "change font size for UI". And I love Atom. And it's difficult choice. I'm upset that there is no active maintainers from the community to keep it alive.

I just installed VSCodium and VSCode to play with it and at first I thought the same, but all you have to do is Ctrl + and Ctrl - to change the UI zoom which changes the UI font size. Effectively the same as Atom UI font size

[ghost]

@raer0 yes, I agree with you. But I don't like VS Code, there are even no such features like "change font size for UI". And I love Atom. And it's difficult choice. I'm upset that there is no active maintainers from the community to keep it alive.

{
    // change font size in editor to a new value. Default 14. Max 100.
    "editor.fontSize": 22
}

In VSCodium

1. Open command palette Ctrl + Shift + P
2. type "settings.json"
3. Input snippet above.

I felt much the same until I gave codium a try and got used to it. I've since found alternatives/upgrades to old tools, ported my custom theme over, and configured keybindings and everything to my liking. I deleted Atom this morning.

[GeorgeZack]

I refuse to use Microsoft programs if I can help it. If Atom is abondonware then that is a shame.

[hermidalc]

Someone on another thread mentioned Electron-based Theia or you can try VSCodium

[vmkalbskopf]

I am running the 1.61 beta, and this is still a problem.

[idoleat]

I am running the 1.61 beta, and this is still a problem.

I'm using 1.61 beta with glibc 2.36 on Arch Linux and atom works fine. What's your environment?