Uncaught TypeError: Cannot read property 'onDidChangeIcon' of null

[ArekSredzki]

Steps to reproduce

Not sure, what exactly causes this erroneous application state. However, once the application enters it, clicking to expand some directories in the file tree causes this error to be thrown. I assume that it happens while trying to get the icon for the files in said directory. Because of the error, it is not possible to see the files in that directory.

In the instance that I'm experiencing right now there is only one file (.yaml) in the problematic directory, no sub folders.

This might have something to do with changes git branches which add new directories.
This error only started occurring a couple of days ago.

Other

Atom: 1.23.2 x64
Electron: 1.6.15
OS: Ubuntu 16.04.3
Thrown From: file-icons package 2.1.16

Stack Trace

Uncaught TypeError: Cannot read property 'onDidChangeIcon' of null

At /home/arek/.atom/packages/file-icons/lib/service/icon-node.js:30

TypeError: Cannot read property 'onDidChangeIcon' of null
    at /packages/file-icons/lib/service/icon-node.js:30:12)
    at Function.forElement (/packages/file-icons/lib/service/icon-node.js:177:17)
    at /packages/file-icons/lib/service/icon-service.js:90:31)
    at IconServices.updateFileIcon (/usr/share/atom/resources/app/node_modules/tree-view/lib/get-icon-services.js:85:37)
    at FileView.module.exports.FileView.updateIcon (/usr/share/atom/resources/app/node_modules/tree-view/lib/file-view.js:45:31)
    at new FileView (/usr/share/atom/resources/app/node_modules/tree-view/lib/file-view.js:30:18)
    at DirectoryView.module.exports.DirectoryView.createViewForEntry (/usr/share/atom/resources/app/node_modules/tree-view/lib/directory-view.js:135:22)
    at /usr/share/atom/resources/app/node_modules/tree-view/lib/directory-view.js:108:32
    at Function.module.exports.Emitter.simpleDispatch (/usr/share/atom/resources/app/node_modules/event-kit/lib/emitter.js:25:20)
    at Emitter.module.exports.Emitter.emit (/usr/share/atom/resources/app/node_modules/event-kit/lib/emitter.js:141:34)
    at Directory.module.exports.Directory.reload (/usr/share/atom/resources/app/node_modules/tree-view/lib/directory.js:395:35)
    at Directory.module.exports.Directory.expand (/usr/share/atom/resources/app/node_modules/tree-view/lib/directory.js:408:18)
    at DirectoryView.module.exports.DirectoryView.expand (/usr/share/atom/resources/app/node_modules/tree-view/lib/directory-view.js:174:30)
    at DirectoryView.module.exports.DirectoryView.toggleExpansion (/usr/share/atom/resources/app/node_modules/tree-view/lib/directory-view.js:160:27)
    at TreeView.module.exports.TreeView.entryClicked (/usr/share/atom/resources/app/node_modules/tree-view/lib/tree-view.js:615:30)
    at HTMLDivElement.<anonymous> (/usr/share/atom/resources/app/node_modules/tree-view/lib/tree-view.js:351:32)

Commands

     -2:39 intentions:highlight (input.hidden-input)
     -2:38.5.0 core:close (input.hidden-input)

Non-Core Packages

atom-beautify 0.30.9 
atom-build-waf 0.2.0 
autocomplete-ctags 0.4.1 
build 0.70.0 
busy 0.7.0 
busy-signal 1.4.3 
dbg 1.6.3 
dbg-gdb 1.7.8 
docblockr 0.13.6 
editorconfig 2.2.2 
file-icons 2.1.16 
file-types 0.5.5 
git-plus 7.10.0 
highlight-selected 0.13.1 
intentions 1.1.5 
language-cmake 1.1.0 
language-cpp14 0.6.2 
language-cuda 0.1.0 
language-diff 0.7.0 
language-doxygen 0.3.0 
language-jade 0.7.2 
language-matlab 0.2.1 
linter 2.2.0 
linter-clang 4.1.2 
linter-ui-default 1.6.10 
minimap 4.29.7 
minimap-find-and-replace 4.5.2 
minimap-git-diff 4.3.1 
minimap-highlight-selected 4.6.1 
minimap-linter 2.1.3 
output-panel 0.3.4 
platformio-ide-terminal 2.8.0 
sync-settings 0.8.3 
tree-view-git-status 1.4.0 
tree-view-open-files 0.3.0 

[Alhadis]

👋 Hey @ArekSredzki, thanks for reporting this. Could you tell me exactly which git commands were being used to update directories, perchance?

[ArekSredzki]

Hi @Alhadis, thanks for the prompt response & great atom package! 😄
Looks like I half-formed the sentence about git usage, my bad.
All I did was git checkout a branch which had a sub directory which didn't exist in the previous. When I clicked to expand the "new" directory the error was thrown. Not sure if it may be relevant but a different subdirectory was also removed at the same time.

[Alhadis]

Did another window have focus when this happened?

Certain file-related events aren't picked up if the Atom window is in the background. It's a known issue I've yet to fix, I'm afraid.

[ArekSredzki]

Atom wasn't in focus since I usually use the terminal for git operations

[ArekSredzki]

Could you add graceful degradation in this case so that the failure to retrieve an icon doesn't disable use of the file tree to navigate those directories? :)

[Alhadis]

This actually shouldn't be happening. Period.

I'll try to have a look at it sometime late this week (probably Friday). 😞 Sorry this is happening.

[VladimirHumeniuk]

Same problem

[WorldSEnder]

Same problem, different setup. In my case, atom was in focus. I deleted a directory with the permanent-delete package and then built using build-scons. When I tried to look into the build directory, this error popped up.

Known workaround: restart atom. Reloading via Ctrl+Shift+F5 seems to work too, although I think I remember one occasion where a simple reload didn't.

[Alhadis]

Hey guys, sorry for the silence. Still trying to wrap up a contract role which is urgently due for end-of-month delivery, and it kinda ate my entire weekend. 😞 I'll hopefully be able to look this soon-ish... giving you all an update for sake of transparency.

I couldn't reproduce this on macOS or Windows, so I'll need to test this with a proper Ubuntu installation to really figure out what's going on here.

[Songworks]

If it helps any, here's a few ways I had the error pop up for me (also only started recently):

• Create a file (select folder in tree-view and hit a) with a name like .xyz. When the error does happen, the file would not show up on tree-view
• When copying some text and accidentily pasting into the tree-view, instead of the text editor. This usually led to a file being created, most of the time the one I have currently selected (with a 0 appended to the name) or any file I copied last
• On executing git merge from cli (*), happens once the commit is being processed (focus was on Atom)

Tried to find a way to consistently reproduce it but no luck yet. :(

Versions:
Atom: 1.23.3
System: Linux Mint 17.3 (based on Ubuntu 14.04)

*: I have setup git hooks for pre-commit which checks coverage and such and it usually creates a temporary directory which is almost instantly deleted.
Perphaps Atom or file-icon is trying to process the directory/files but they get deleted before either can finish the (asyncronous?) task? Just a thought.

[joaopedromattos]

Same problem, different setup: I've just tried to open a folder as a project folder.
*OS: Linux Mint 18.3
*Atom version: 1.23.3

[Willyham]

For me it seems to happen inconsistently when trying to use Ctrl + P to bring up the file search menu. After the error occurs, that menu no longer works and I have to restart atom. Fedora 27.

[kalinchernev]

I'm having this issue popping up every time I move files around. I don't see any problems in the file tree. Please allow suppressing this message somehow, I already start considering removing the package as the error message is worse than the issue itself ...

[Alhadis]

To everybody experiencing this problem:

You can disable IO completely and force the package not to make any filesystem read/access attempts. Doing this will make hashbang, modeline and fallback signature detection unavailable, but it's better than disruptive crap like this.

To disable IO, uncheck the following options in the package settings:

• Check hashbangs
• Check modelines
• Use .gitattributes

I recommend restarting the editor after changing these settings, just to be on the safe side.

If you're STILL getting this error, then it's indicative of a much more serious problem.

[Alhadis]

Allllrighty. Due to the (obviously) nasty nature of the issue, and the fact that I haven't been able to reproduce it (even on Ubuntu), I'm taking a leaf from @kalinchernev's book and suppressing the damn message until I can work out what the actual fuck is going on here.

Until then, if any of you see a missing icon in the tree-view, that'll be because of how I "fixed" this issue. If you think it's inelegant, well... I agree. Just remember I could have chosen a worse fallback.

[Songworks]

I haven't had the issue since updating Atom to 1.24. Not sure if it's just a fluke though considering how sporadic the error is. For now I'll continue to use the package without the fix and see what happens.

[Alhadis]

Gonna roll a release soon anyway, so you won't see this issue even if it is a fluke. =)

[Alhadis]

@sylvanr Are you saying you're still witnessing this issue even after installing the latest version of both file-icons and Atom?

If so, could you please tell me what packages and themes are installed? Note what I said before about switching off IO in the package's settings.

[sylvanr]

@Alhadis I see my mistake, the issue was indeed solved by updating Atom to 1.24. Thank you.

[WorldSEnder]

I dove a bit into this issue, with additional logging. It seems that the received resource is marked as destroyed.

		if(delegate == null) {
			throw "Resource has no delegate, " + resource.destroyed;
		}

which logs Uncaught Resource has no delegate, true.
EDIT: I will try to come up with a PR if I find the cause for this.

[Alhadis]

@WorldSEnder Yes, but resources shouldn't be destroyed so soon after a delegate is created (since delegates are created whenever resources are referenced for the first time). By memory, this all happens synchronously, which means it can't be a race condition. If anything, it's probably connected to some underlying platform-specific logic. 😕

EDIT: I will try to come up with a PR if I find the cause for this.

Don't get too carried away. 😉 The culprit probably lies in the atom-fs module, and it's due for major refactoring (which will probably fix the original issue anyway).