Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

In some scenarios, opening Atom on Linux results in 100% CPU usage of a core #13317

Closed
joefitzgerald opened this issue Nov 23, 2016 · 10 comments
Closed
Assignees
Labels

Comments

@joefitzgerald
Copy link
Contributor

  • When some Linux users open Atom via .desktop files or via the gnome launcher, they experience 100% CPU usage due to the way we are invoking the shell to patch the user's environment
  • This does not happen for all Linux users
  • This does seem to happen consistently for users on Arch Linux
  • The shell is invoked with detached: false and using the -i flag for an interactive shell
    • The intent of shelling out to get the environment is to run the same shell initialization scripts that are run when a user opens a terminal window and invokes atom from there
    • Removing the -i flag is not the solution, because it doesn't result in the desired behavior; it does result in the shell exiting as expected without consuming 100% of a CPU core
    • Adding detached: true to the options used for child_process.spawn does fix the issue and retains the desired behavior, but it requires additional code to manage the process lifecycle if Atom exits or an Atom window is reloaded while the shell process is still running

The below is a copy of #13084 (comment), included here to open up a new issue:

@phw says:

I debugged this a bit and can reproduce it with the following test script (extracted from [src/update-process-env.js](https://github.com/atom/atom/blob/1b2d2f029945c58cf4cd474ef1423856b35cf26c/src/update-process-env.js)):

```javascript
const childProcess = require('child_process')
const cmd = 'command env'
const shell = process.env.SHELL  // zsh or bash doesn't matter, behavior is the same
// const shell = '/bin/bash'

const child = childProcess.spawn(shell, ['-ilc', cmd], {
   encoding: 'utf8',
  //  detached: true,
  stdio: ['ignore', 'pipe', process.stderr]
})
child.on('error', (e) => {
  console.log('error', e)
})
child.stdout.on('data', (data) => {
  console.log(data.toString('utf8'))
})
child.on('close', (code, signal) => {
  console.log('close', code, signal)
})
```

Launching this directly from a shell works, even if I set an empty environment like so:

    env -i SHELL=/bin/bash node spawn.js

Launching the same from a desktop file in Gnome 3.22 leads to the shell task endlessly consuming 100% of CPU. I used the following desktop file:

```
[Desktop Entry]
Name=Spawn Node Test
Exec=env SHELL=/bin/bash node /home/phw/devel/spawn.js
Icon=atom
Type=Application
```

Two things help to solve this issue:

a) Enable `detached: true` when spawning the child process
b) Remove the `-i` flag from the shell call

I think b) would actually be correct anyway, since this is in no way an interactive shell.

EDIT: Just to be clear: I still don't know exactly *why*  this is happening, I just know the issue can be circumvented removing the `-i` flag.
@joefitzgerald joefitzgerald self-assigned this Nov 23, 2016
@joefitzgerald joefitzgerald changed the title In some scenarios, opening atom on Linux results in 100% CPU usage of a core In some scenarios, opening Atom on Linux results in 100% CPU usage of a core Nov 23, 2016
@phw
Copy link

phw commented Nov 23, 2016

Maybe some other interesting fact: If Atom is launched via the desktop file and consequently spawns this non-terminating shell process, some actions (New file, About, maybe others) do not react. That is you trigger the action (via menu, keyboard shortcut, command palette, doesn't matter) but there is no action.

However, once you kill the spawned shell process the triggered actions get executed. E.g. you hit two times Ctrl+N and also start "Application: About" via command palette, nothing visible happens. You kill the spawned shell process and suddenly two new file editors and the about window are opened.

Maybe somebody has an idea how this is related.

@garretraziel
Copy link

It is happening to me on my system, when I click on "restart" after package update (it was update of nucleus-dark-ui). Fedora 25, Atom 1.12.5 installed from rpm downloaded directly from atom.io.

@joefitzgerald
Copy link
Contributor Author

@phw please try building from source (use the master branch) and let me know if this has resolved your issue.

@joefitzgerald
Copy link
Contributor Author

@phw or others affected by this: in order to release a hotfix, we want one of you to build from source on Linux and verify the issue is fixed. Could you please assist us in doing this?

@phw
Copy link

phw commented Nov 26, 2016

I'd love to test this, but I likely won't be able to do so before Monday.

@janeerik
Copy link

Just built from source and seems to have fixed the problem in my case (running ubuntu 16.04 LTS).

@ezickler
Copy link

ezickler commented Nov 27, 2016

Would like to try but i'm unable to compile atom. I think some nodejs problem with fedora but tried with packagemanger and nodejs installed over nvm. Dosn't work for me. Sry. I don't get this node stuff.

error from calling script/build:

Node: v7.2.0
Npm: v3.10.9
Installing script dependencies
Installing apm
../src/onig-string.cc: In constructor ‘OnigString::OnigString(v8::Localv8::String)’:
../src/onig-string.cc:25:40: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
hasMultiByteChars = (value->Length() != utf8_length_);
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
../deps/libgit2/deps/zlib/inflate.c: In function ‘inflateMark’:
../deps/libgit2/deps/zlib/inflate.c:1507:61: warning: left shift of negative value [-Wshift-negative-value]
if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16;
^~
child_process.js:145
throw new TypeError('Incorrect value of args option');
^

TypeError: Incorrect value of args option
at Object.exports.execFile (child_process.js:145:11)
at Object.exports.exec (child_process.js:108:18)
at Object. (/tmp/atom/apm/node_modules/atom-package-manager/script/postinstall.js:10:16)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
at Module.runMain (module.js:605:10)
at run (bootstrap_node.js:420:7)
npm ERR! Linux 4.8.8-300.fc25.x86_64
npm ERR! argv "/usr/bin/node" "/tmp/atom/script/node_modules/.bin/npm" "--global-style" "--loglevel=error" "install"
npm ERR! node v7.2.0
npm ERR! npm v3.10.5
npm ERR! code ELIFECYCLE

npm ERR! atom-package-manager@1.15.1 install: node script/postinstall.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the atom-package-manager@1.15.1 install script 'node script/postinstall.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the atom-package-manager package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node script/postinstall.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs atom-package-manager
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls atom-package-manager
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /tmp/atom/apm/npm-debug.log
npm ERR! code 1
child_process.js:511
throw err;

@PAStheLoD
Copy link

Hello,

Just to make sure this is the same bug, I get the same behavior, with the same bash -ilc command env trapped in an infinite signal handling loop (see also), with bash 4.4:

strace: Process 19539 attached
--- SIGTTIN {si_signo=SIGTTIN, si_code=SI_USER, si_pid=19539, si_uid=1000} ---
rt_sigaction(SIGTTIN, {SIG_IGN, [], SA_RESTORER, 0x7fba456ab860}, {SIG_DFL, [], SA_RESTORER, 0x7fba456ab860}, 8) = 0
ioctl(255, TIOCGPGRP, [19683])          = 0
rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7fba456ab860}, {SIG_IGN, [], SA_RESTORER, 0x7fba456ab860}, 8) = 0
kill(0, SIGTTIN)                        = 0
...

If I try to strace the start of atom strace -f -e execve -s 300 -o /tmp/atom.trace atom . in my $HOME, atom starts normally (maybe because using strace changes the process group structure).

@phw
Copy link

phw commented Nov 29, 2016

@joefitzgerald I finally was able to test this, looking very good 👍 I tried with latest master, starting Atom from the .desktop file works as expected. Just to be sure I also installed the revision just before the merge of your fix (03cc503), and as expected the issue was there again.

Thanks for this fix :)

@lock
Copy link

lock bot commented Apr 4, 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@lock lock bot locked and limited conversation to collaborators Apr 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants