Opening 2 related folders in child, parent order crashes Atom


#1

I’m having an issue with opening 2 related folders at the same time. Say I have /somedir and /somedir/node_modules. I seem to be ok if I File > Open Folder the parent and then the child. But if I open the child then the parent, Atom’s CPU use spikes and memory consumption climbs until the second window crashes. Anyone else see this behavior? Atom 0.153.0 Win 7 x64.


#2

Have you tried running atom --safe to be sure this isn’t package related problem?


#3

Thanks for the reply.

If I start Atom in safe mode and open additional windows from there, e.g. using File > Open Folder, are those Atom windows also opened in safe mode? (I’m guessing no.)

Is there no indication in the UI that you’re running in safe mode?

I tried opening Atom in safe mode then using File > Open Folder on the child then the parent and get the same result (crash). If I run atom --safe twice and then do File > Open Folder on the child in the first window and on the parent in the second window, I don’t get the crash, but in that case Atom also doesn’t restore the workspace (open files) like it does when I run atom --safe once and use the UI from there.

So to summarize:

atom --safe
File > Open Folder (child)
File > Open Folder (parent)
== crash

atom --safe
File > Open Folder (child)
atom --safe
File > Open Folder (parent)
== no crash and no restored workspaces

#4

Indeed, they are not opened in safe mode.

You can run atom.getLoadSettings().safeMode in the console, which returns true or false. As far as I know there is no indidication for safe mode directly. If you have a custom (syntax) theme the console will warn you that it isn’t installed, since only core packages are loaded in safe mode, but in that case you probably notice it anyway since the editor looks different.

I agree that a dev-mode like indication would be a nice addition. Perhaps a green ‘color-mode’ octicon, seeing as it’s used in red for dev-mode?


#5

Would you mind opening an Issue for the safe mode icon @Alchiadus?


#6

Looking at the code I thought it’d be trivial to implement the feature (essentially it’s identical to dev mode), so I started to hack away. Then I realized when I started Atom in safe mode to see if it was working my cloned package wouldn’t be loaded (doh… safe mode and all…). Is there an easy way to test it?


#7

You could possibly copy it into the Atom application directory structure?


#8

That doesn’t seem to work for me. I removed the status-bar folder in Atom\resources\app\node_modules\status-bar and replaced it with my edited version. After starting up Atom in safe mode I had no status bar anymore. I stashed my changes, restarted Atom in safe mode and again no status bar. I restored the packaged status-bar from the Recycle Bin and sure enough a status bar appeared. Finding it a little hard to believe I managed to break something with such a small change I cloned the status-bar repo directly into the folder, restarted Atom in safe mode and once again no status bar.

The only logical thing I could think of was that the repo had a newly released version that isn’t pulled into Atom’s package.json yet, but both are at 0.53.0.


#9

Don’t the default installed packages get compiled to JS on build? Maybe Atom isn’t compiling them for you and it won’t load uncompiled CoffeeScript from those directories or something?


#10

You’re absolutely right, completely missed that, thanks!


#11

Guys, where you able to reproduce @jmm problem? I have tried it on Atom 0.155 Win 7, but without problems. @jimm have you tried to remove all installed packages, just to be sure. Do you have any errors in console in child folder?

PS: @leedohm, @Alchiadus I noticed one small thing. If I second open atom(as jmm did) and then open folder so another atom window pops up atom.getLoadSettings().safeMode returns undefined in second window instead of false/true.


#12

I haven’t tried it, no. I’ve been busy with other things, unfortunately.


#13

@Trudko I cannot reproduce the issue, opening child folders from within the parent and vice versa works fine for me (Atom `0.161.0).

It looks like if an Atom instance is launched from within Atom it is ‘special’, devMode is also undefined for example. I don’t know much of the internals of Atom’s start up behaviour, so I cannot say why.

Edit: If you open another Atom window in dev mode atom.getLoadSettings().devMode is no longer undefined but correctly set to true.


#14

@Alchiadus it seems like bug don’t you think @leedohm?


#15

Ok, thanks. That’s counterintuitive to me. I expected the window spawned by the safe mode window to also be in safe mode.

Ok, thanks for the tip.

Right…I’m running mostly stock, so no visible difference.

Thanks for the work on that.

I tried removing all installed packages and behavior was the same in non-safe mode. No errors in console in child folder (1st opened) window. I never get the chance to see the console in the parent folder (2nd opened) window.

I suspected it might have something to do with the session restoration rather than the folder structure, but my session finally got blown away and the problem didn’t stop. The problem is more general than I originally realized though. Opening the same folder (parent folder from original scenario) twice has the same problem. It seems that opening this “parent” folder second to any folder exhibits the problem.

These folders are on a samba share. Currently this causes a crash (interpret folder as a literal name, not a placeholder for *):

File > Open Folder (\\server\share\folder)
File > Open Folder (\\server\share\folder) <- crashes

Currently this does not cause a crash (where Z: is mapped to \\server\share and folder is the same as above):

File > Open Folder (Z:\folder)
File > Open Folder (Z:\folder)

// Also, this (3rd invocation) does nothing -- fails silently
File > Open Folder (Z:\folder)

The UNC paths are what I had been using up to the point that the problem originally showed up, so I don’t know if there’s some fundamental difference between the UNC path and the other one, or if perhaps the problem is related to some data Atom is still hanging on to (e.g. session) in connection with the UNC path.

Does Atom generate any log files that might shed any light on this?

Also, while debugging this I notice that without any Atom windows open I have 3 atom.exe processes hanging around. What’s that about?


#16

Yes, it does seem like a bug.


#17

@leedohm ok I added issue https://github.com/atom/atom/issues/4690.