Files won't open files after a while of usage

[Gabriel_P]

This is hard to debug/reproduce but I'm opening a new bug for the sake of completeness.

After a while of working with some tabs opened, Files refuses to open files anymore. I can move around Files with no issues (inside/outside folders) and the app seems responsive in every way, but no matter what I try (click, double click, right click + select app to open, hitting the 'Return' key) no file will open.

The only fix is to close and re-open files.

[Gabriel_P (gabp)]

$ dpkg -s pantheon-files
Package: pantheon-files
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 3370
Maintainer: Cody Garver <email address hidden>
Architecture: amd64
Version: 0.2.0.1-0~r1815+pkg38~ubuntu0.3.1

Will try running pantheon-files -d to see if I can come up with something to add to this bug.

[Gabriel_P (gabp)]

Tried running pantheon-files -d and played around for a while until it stopped opening files. I'm now pretty sure it has something to do with the generation of images' thumbnails.

In any case, this is something I believe appeared (although inconsistently) when attempting to open a file (I tried with image files mostly) and getting nothing.

[_LOG_LEVEL_DEBUG 10:09:27.058157] marlin_icon_info_finalize (null) (null) ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058214] marlin_icon_info_finalize (null) (null) ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058243] marlin_icon_info_finalize (null) (null) ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058270] marlin_icon_info_finalize (null) (null) ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058297] marlin_icon_info_finalize (null) (null) ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058322] marlin_icon_info_finalize (null) (null) ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058348] marlin_icon_info_finalize (null) (null) ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058373] marlin_icon_info_finalize (null) folder-pictures ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058397] marlin_icon_info_finalize (null) selection-remove ref_count 1
[_LOG_LEVEL_DEBUG 10:09:27.058430] marlin_icon_info_finalize (null) drive-harddisk ref_count 6
[_LOG_LEVEL_DEBUG 10:09:27.058455] marlin_icon_info_finalize (null) network-server ref_count 3
[_LOG_LEVEL_DEBUG 10:09:27.058480] marlin_icon_info_finalize (null) user-home ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058505] marlin_icon_info_finalize (null) folder ref_count 5
[_LOG_LEVEL_DEBUG 10:09:27.058530] marlin_icon_info_finalize (null) selection-checked ref_count 1
[_LOG_LEVEL_DEBUG 10:09:27.058559] marlin_icon_info_finalize (null) text-plain ref_count 12
[_LOG_LEVEL_DEBUG 10:09:27.058584] marlin_icon_info_finalize (null) folder-download ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058609] marlin_icon_info_finalize (null) network-workgroup ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058636] marlin_icon_info_finalize (null) image-x-generic ref_count 1
[_LOG_LEVEL_DEBUG 10:09:27.058665] marlin_icon_info_finalize (null) user-trash-full ref_count 2
[_LOG_LEVEL_DEBUG 10:09:27.058690] marlin_icon_info_finalize (null) selection-add ref_count 1

Not sure if this helps, please tell me if I'm just posting garbage.

[Gabriel_P (gabp)]

This is something else I keep seeing after files refuses to open files anymore:

OverlayBar.vala:208: Se canceló la operación

(the last sentence translates to: Operation was cancelled)

Again, not sure if relevant. Let me know if I can do something else to help debug this.

[Jeremy Wootten (jeremywootten)]

It may be that the list model for the view may contain invalid file objects or icon-info objects for image files (the Overlay bar is trying and failing to find out the resolution of the image).

Does
(1) reloading the tab or
(2) closing the tab and then navigating back to the problematic folder in a new tab

clear the problem, rather than closing and reopening the whole application. These actions should rebuild the list model.

[Gabriel_P (gabp)]

Tried

(1) reloading the tab hitting F5 --> no change
(2) close the tab & navigate back --> no change
(3) close all tabs (ie: back to home folder) --> no change

By 'no change' I mean no file will open (images, plain text, pdfs, executables, .jar containers, etc)

The app remains perfectly usable other than that.

[Gabriel_P (gabp)]

Add: no file will open in *any folder*, not only those that were opened when the app stopped working.

[Jeremy Wootten (jeremywootten)]

Thanks for the additional information; it rules out a number of possible causes. If you notice any common factor with respect to what was happening immediately prior to Files ceasing to open files please let us know.

[Gabriel_P (gabp)]

I'm pretty sure this has something to do with the way the paths of each tab are stored.

This is what I see after closing/opening Files with several tabs opened (see attached images):

1- When first moving into a tab, the path displayed in Files is not correct (see 01.png and notice it does not match what dconf shows)

2- After clicking on a different tab and then back to that tab, the path is shown in Files correctly (see 02.png, now the paths in files and dconf matches)

[Gabriel_P (gabp)]

Attaching 02.png (why doesn't Launchpad allow you to attach more than one file?!)

[Gabriel_P (gabp)]

Is there a way to disable the generation of thumbnails? I'm think that could be responsible for this issue also.

[Gabriel_P (gabp)]

Found it: http://askubuntu.com/questions/518889/how-to-disable-thumbnail-generation

Sorry for post bombing, will stop now.

[Gabriel_P (gabp)]

The method described in the askubuntu question to stop thumbnails from being generated did not work.

Also, I just realized that when Files starts refusing to open files it also stops being able to open a a folder in Terminal.

[Jeremy Wootten (jeremywootten)]

When Files stops opening files, could you open up System Monitor and check whether Files is consuming cpu cycles? Thanks

[Gabriel_P (gabp)]

OK, I think I've found what could be the cause here.

I did as Jeremy requested and, once Files refused to open files anymore, I checked its CPU usage.

What I found (see attached image) is that it is eating up all the virtual memory, which could quite possible be the reason it stops working.

[Gabriel_P (gabp)]

To clarify: I initially assumed VIRT was equal to SWAP, but I see now that it is more complicated than that.

Either way, I can see a clear correlation here and I've been able to reproduce this issue consistently simply by opening large images, which makes VIRT grow.

When VIRT gets too high (around the 10Gb mark), Files stops opening files. I can keep *trying* to open files, and even if nothing happens, VIRT keeps getting higher.

[Gabriel_P (gabp)]

Oh, I also tried setting 'swappiness' from the default value of 60 to zero with:

sudo sysctl vm.swappiness=0

After rebooting, the issue is still there.

[Jeremy Wootten (jeremywootten)]

Thanks for the additional information. Files is known to leak some memory but not that much! When you say "open large images" do you open them individually or are they all open at the same time? How large are the images and how many do you have to open? It probably doesn't matter, but which application are you opening the images with?

[Gabriel_P (gabp)]

Here's a vid of me opening images (around 40 so its a little long) until Files reaches a high VIRT and stops opening them. I open them one at a time and I even close one before opening the next one.

The images seen on the vid are all around 3Mb in size and I use Viewnior as my default image viewer.

Around 2:40, when the VIRT is over 8Gb, I show that clicking any image does not open it anymore but the VIRT keeps on increasing nonetheless.

https://youtu.be/ZxWAzUciBbA

[Jeremy Wootten (jeremywootten)]

Very interesting! I have now reproduced this myself and have found that it is nothing to do with opening and closing of files - even moving the mouse rapidly backwards and forwards over the icons causes virtual memory usage to permanently rise - eventually to such levels that Files is unable to open another application. This had not been noticed before as I usually only monitor physical memory use.

I have now narrowed down the source of the leak to the updating of the Overlay bar - I will not have time to fix it for a day or two but will give it priority.

Thanks for your help.

[Gabriel_P (gabp)]

Glad to hear you've found (or are very close to find) the source of the issue!

Files is hands down the best files manager for Linux (I tried most of them in the last few days) and nothing comes close to its usability.

Thank you for giving this issue priority. For those of us who make heavy use of the file manager, actually opening files is a big part of the process :P

Cheers and let me know if there's anything else I can do to help you.