Thumbnail creation for EPS files sometimes gets Nemo stuck

[cschreib]

 * Nemo version 3.8.5
 * Windowed nemo
 * Distribution - Mint 19.0
 * Intel Corporation UHD Graphics 620, xserver-xorg-video-intel (2:2.99.917+git20171229-1)
 * 64 bit

Issue
Rendering the thumbnail for some EPS files seems to get nemo stuck somehow, indefinitely displaying the "loading" cycling arrow in the bottom right corner (until navigating to a different folder). During this time, the offending EPS file does not even appear in the window, as if the file was missing. When this happens, the "reload" command (F5) is not functional, and the only way to make the problem go away is to navigate to a different directory and come back. This appears to be specific to this file type, as the same file converted to PDF always displays reliably.

Steps to reproduce
I was not able to reproduce the problem consistently, but I describe below one scenario during which the problem occurred at least once. Once I get the problem to occur with one particular EPS file, I can reliable repeat it by modifying the EPS file (any modification, just to invalidate the thumbnail cache). However it does not occur systematically with all EPS files. Worse, if the problem occurs for a specific file and I make a copy of this file with a different name, then the problem usually does not occur for this copy, even though the actual data in the file is exactly the same...

Scenario where this happened once:

First install the package gnudatalanguage from the official repository (Mint or Ubuntu, whatever). This is a tool for data analysis and visualization. Then copy the code below in a file called test.pro in a directory of your choice (where you have write permission).

file_mkdir, 'tmp/'

set_plot, 'ps', /interpolate
device, filename='tmp/plot.eps', xsize=9, ysize=9, /color, /decomposed, /encapsulated, bits_per_pixel=8
!p.background = 'ffffff'x
!p.color = 0

seed = 42
data = randomn(seed, 512, 512)

tv, data

device, /close

end

Open a terminal in this directory and launch the GDL interpreter with the command gdl. Once inside the GDL interpreter, type .r test.pro and press Enter.

This will create a new directory called tmp, containing the EPS file plot.eps. With nemo, open the tmp directory and see if the file is indeed there. It will take a bit of time to generate the thumbnail (I must say, more time than it should for such a small file), but it should work.

Then with nemo go to the parent directory, so the file is not displayed in nemo anymore. Now re-run the GDL steps above to create the EPS file again. Then with nemo go back inside the tmp directory and this is when the problem sometimes occurs.

Expected behaviour
If there is an issue with creating a thumbnail, I would expect nemo to at least show the file without the thumbnail rather than indefinitely hang and not show the file at all. And of course, I would also expect the thumbnail rendering not to fail in the first place!

Other information
GDL is an open source clone of IDL, a similar tool which is proprietary and closed source. I experienced this problem with EPS files created with either GDL or IDL, so this is not related to these particular softwares.

Given the problem is hard to reproduce, I'm happy to try to debug things locally, if you point me to the right direction. I should also note that this is a problem I have experience with nemo for several years now, and it did not appear in a recent version.

When I experience the problem with one particular file, I have tried clearing the thumbnail cache (~/.cache/thumbnails/), but this did not change anything. However it seems that killing nemo and restarting it does make the problem go away (for that particular file) until the next time it happens again.

[mtwebster]

I was able to reproduce this initially, but as soon as I hook up a debugger it goes away, I'll keep trying. If you'd like, try something like this to see if we can get something useful:

First, enable -dbgsym repos if you don't have them already (unlikely - this is tedious, but out of our control - we're going to automate it) - instructions here:

https://wiki.ubuntu.com/Debug%20Symbol%20Packages

then,

sudo apt-get install nemo-dbg libcinnamon-desktop-dbg libgtk-3-0-dbgsym libglib2.0-0-dbgsym libcairo2-dbgsym libgdk-pixbuf2.0-0-dbgsym gdb

# kill any running nemo
nemo --quit

# debug
NEMO_DEBUG=Thumbnails G_MESSAGES_DEBUG=all gdb nemo
# once in debugger,
run
# try to reproduce issue to the point where folder/file is not displaying and unable to reload, then ctrl-c
# get traces
thread apply all bt

As a (temporary hopefully) workaround, you can disable thumbnailing of eps files:

gsettings set org.cinnamon.desktop.thumbnailers disable "['image/jp2', 'image/x-eps']"

(the jp2 is there by default already)

[mtwebster]

Another thing to try is, either remove xreader temporarily (specifically xreader-common package) or simply rename /usr/share/thumbnailers/xreader.thumbnailer to xreader.thumbnailer.disabled and install evince. I'm curious if the same behavior exists with evince's thumbnailer.

[cschreib]

The problem also happens with evince.thumbnailer. Looking into gathering debug info...

[cschreib]

Managed to reproduce it. Here is the gdb log from the moment I stepped inside the directory with the offending file:

[New Thread 0x7fffd2b41700 (LWP 10543)]
[New Thread 0x7fffdbfff700 (LWP 10544)]
[Thread 0x7fffdbfff700 (LWP 10544) exited]
[Thread 0x7fffd8953700 (LWP 10541) exited]
[Thread 0x7fffd2b41700 (LWP 10543) exited]
^C
Thread 1 "nemo" received signal SIGINT, Interrupt.
0x00007ffff3cd9bf9 in __GI___poll (fds=0x5555559478b0, nfds=3, timeout=20000) at ../sysdeps/unix/sysv/linux/poll.c:29
29	in ../sysdeps/unix/sysv/linux/poll.c
(gdb) thread apply all bt

Thread 4 (Thread 0x7fffe881c700 (LWP 10280)):
#0  0x00007ffff3cd9bf9 in __GI___poll (fds=0x555555a11710, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff5923439 in g_main_context_poll (priority=<optimised out>, n_fds=1, fds=0x555555a11710, 
    timeout=<optimised out>, context=0x555555a0f680) at ../../../../glib/gmain.c:4204
#2  g_main_context_iterate (context=context@entry=0x555555a0f680, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimised out>) at ../../../../glib/gmain.c:3898
#3  0x00007ffff592354c in g_main_context_iteration (context=0x555555a0f680, may_block=1)
    at ../../../../glib/gmain.c:3964
#4  0x00007fffe882436d in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#5  0x00007ffff594ae05 in g_thread_proxy (data=0x7fffdc010280) at ../../../../glib/gthread.c:784
#6  0x00007ffff3fbd6db in start_thread (arg=0x7fffe881c700) at pthread_create.c:463
#7  0x00007ffff3ce688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffe922a700 (LWP 10279)):
#0  0x00007ffff3cd9bf9 in __GI___poll (fds=0x7fffcc001fd0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff5923439 in g_main_context_poll (priority=<optimised out>, n_fds=4, fds=0x7fffcc001fd0, 
    timeout=<optimised out>, context=0x5555559cc230) at ../../../../glib/gmain.c:4204
#2  g_main_context_iterate (context=0x5555559cc230, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimised out>) at ../../../../glib/gmain.c:3898
#3  0x00007ffff59237d2 in g_main_loop_run (loop=0x5555559cc370) at ../../../../glib/gmain.c:4099
#4  0x00007ffff5f0fe76 in gdbus_shared_thread_func (user_data=0x5555559cc200) at ../../../../gio/gdbusprivate.c:275
#5  0x00007ffff594ae05 in g_thread_proxy (data=0x55555599f000) at ../../../../glib/gthread.c:784
#6  0x00007ffff3fbd6db in start_thread (arg=0x7fffe922a700) at pthread_create.c:463
#7  0x00007ffff3ce688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffe9a2b700 (LWP 10278)):
#0  0x00007ffff3cd9bf9 in __GI___poll (fds=0x5555559c43e0, nfds=2, timeout=3996)
    at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff5923439 in g_main_context_poll (priority=<optimised out>, n_fds=2, fds=0x5555559c43e0, 
    timeout=<optimised out>, context=0x5555559c4100) at ../../../../glib/gmain.c:4204
#2  g_main_context_iterate (context=context@entry=0x5555559c4100, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimised out>) at ../../../../glib/gmain.c:3898
#3  0x00007ffff592354c in g_main_context_iteration (context=0x5555559c4100, may_block=may_block@entry=1)
    at ../../../../glib/gmain.c:3964
#4  0x00007ffff5923591 in glib_worker_main (data=<optimised out>) at ../../../../glib/gmain.c:5773
#5  0x00007ffff594ae05 in g_thread_proxy (data=0x555555967720) at ../../../../glib/gthread.c:784
#6  0x00007ffff3fbd6db in start_thread (arg=0x7fffe9a2b700) at pthread_create.c:463
#7  0x00007ffff3ce688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ffff7fb6080 (LWP 10274)):
#0  0x00007ffff3cd9bf9 in __GI___poll (fds=0x5555559478b0, nfds=3, timeout=20000)
    at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff5923439 in g_main_context_poll (priority=<optimised out>, n_fds=3, fds=0x5555559478b0, 
    timeout=<optimised out>, context=0x555555944c20) at ../../../../glib/gmain.c:4204
#2  g_main_context_iterate (context=context@entry=0x555555944c20, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimised out>) at ../../../../glib/gmain.c:3898
#3  0x00007ffff592354c in g_main_context_iteration (context=context@entry=0x555555944c20, may_block=may_block@entry=1)
    at ../../../../glib/gmain.c:3964
#4  0x00007ffff5ee3d2d in g_application_run (application=0x55555593e130, argc=<optimised out>, argv=<optimised out>)
    at ../../../../gio/gapplication.c:2470
#5  0x0000555555588a82 in main (argc=1, argv=0x7fffffffd638) at ../../src/nemo-main.c:104

It took a while before I could get the bug to trigger. But what seems to have triggered it was when I had the EPS file already open with xreader in the background.

In contrast, here is the debug output that got printed when nemo was successful in creating the thumbnail:

[New Thread 0x7fffd3fff700 (LWP 10446)]
[New Thread 0x7fffd2b41700 (LWP 10447)]
[New Thread 0x7fffd8953700 (LWP 10448)]
** (nemo:10274): DEBUG: 13:35:40.351: nemo_create_thumbnail: ../../libnemo-private/nemo-thumbnails.c:490: (Main Thread) Locking mutex
** (nemo:10274): DEBUG: 13:35:40.351: nemo_create_thumbnail: ../../libnemo-private/nemo-thumbnails.c:508: (Main Thread) Adding thumbnail: file:///home/cschreib/code/uvj_templates/plots/uvj_obs.eps
** (nemo:10274): DEBUG: 13:35:40.351: nemo_create_thumbnail: ../../libnemo-private/nemo-thumbnails.c:535: (Main Thread) Unlocking mutex
** (nemo:10274): DEBUG: 13:35:40.364: thumbnail_thread_starter_cb: ../../libnemo-private/nemo-thumbnails.c:171: (Main Thread) Creating thumbnails thread
[New Thread 0x7fffdbfff700 (LWP 10449)]
** (nemo:10274): DEBUG: 13:35:40.365: thumbnail_thread_start: ../../libnemo-private/nemo-thumbnails.c:554: (Thumbnail Thread) Locking mutex
** (nemo:10274): DEBUG: 13:35:40.365: thumbnail_thread_start: ../../libnemo-private/nemo-thumbnails.c:601: (Thumbnail Thread) Unlocking mutex
** (nemo:10274): DEBUG: 13:35:40.365: thumbnail_thread_start: ../../libnemo-private/nemo-thumbnails.c:622: (Thumbnail Thread) Creating thumbnail: file:///home/cschreib/code/uvj_templates/plots/uvj_obs.eps
** (nemo:10274): DEBUG: 13:35:40.499: thumbnail_thread_start: ../../libnemo-private/nemo-thumbnails.c:554: (Thumbnail Thread) Locking mutex
** (nemo:10274): DEBUG: 13:35:40.499: thumbnail_thread_start: ../../libnemo-private/nemo-thumbnails.c:585: (Thumbnail Thread) Exiting
** (nemo:10274): DEBUG: 13:35:40.499: thumbnail_thread_notify_file_changed: ../../libnemo-private/nemo-thumbnails.c:361: (Thumbnail Thread) Notifying file changed file:0x555556592360 uri: file:///home/cschreib/code/uvj_templates/plots/uvj_obs.eps

[Thread 0x7fffdbfff700 (LWP 10449) exited]
[Thread 0x7fffd8953700 (LWP 10448) exited]
[Thread 0x7fffd3fff700 (LWP 10446) exited]

None of this type of debugging strings were printed when the bug occurred.

[xenopeek]

I can't manage to reproduce this issue on Linux Mint 20 Cinnamon. If you're still affected, would you retest on Linux Mint 20 Cinnamon?

[cschreib-ibex]

I'm on 19.3 at the moment (Nemo 4.4.8) and still can reproduce the issue. I will try with Mint 20 on a live usb when I find the time.

[SebastJava]

Issue
Rendering the thumbnail for some EPS files seems to get nemo stuck somehow, indefinitely displaying the "loading" cycling arrow in the bottom right corner (until navigating to a different folder). During this time, the offending EPS file does not even appear in the window, as if the file was missing. When this happens, the "reload" command (F5) is not functional, and the only way to make the problem go away is to navigate to a different directory and come back. This appears to be specific to this file type, as the same file converted to PDF always displays reliably.

I get the exact same problem with SVG files! I am on Linux Mint Cinnamon 20 (64bits). I saw this problem occurring many times before, but never took the time to report until now. Now i am trying to reproduce it, to understand WHEN this happens, because it does not happen all the time. I am currently trying to find WHEN this problem occurs...

[cschreib]

Confirmed that I can still reproduce the issue in Mint 20 with the instructions in the issue description. I have also had it occur with PNG files created by GIMP (although I haven't yet managed to get a reproducible method). So I agree with @SebastJava that this is probably not limited to EPS.

From the issue description, the general procedure seems to be:

• create a new file, for the very first time (nemo must have never seen that file before).
• have nemo generate a new thumbnail for that file by opening the containing directory: this works.
• make sure nemo is no longer viewing this directory (close nemo, or switch to another directory)
• update the file somehow (re-generate it, modify it externally, etc.). I assume this cannot use any graphical "Save..." dialogue, as this could interfere with the thumbnail caching process and accidentally hide the problem.
• view the containing directory with nemo again: problem occurs.

[SebastJava]

I had another very similar issue that i wanted to investigate and systematically reproduce and report a long time ago.
Thumbnails are not updated when editing SVG files after having renamed them: #2621

I am still struggling to reproduce this one here, the #1922. I tried the "general procedure" described above but yet failed to reproduce this bug. On point 4, "update the file somehow", i changed the color on an SVG file using nano in the Terminal. I had no trouble with the thumbnails, this time. But i did experience this bug just a few weeks ago. So i am still trying to systematically reproduce it.

[SebastJava]

I also ended up with Nemo being stuck on a file it can’t display. Some infinite loop... But my steps are totally different from yours, so i don’t know if this is related or not. So i have this other issue, as mentioned earlier, and now this little "bonus" update: #2621 (comment)

Sorry, i am probably just adding to the confusion. I have to slow down and try to think. I had too much coffee. :)
I am still saying i had an issue similar to yours, but failed to reproduce it. I keep searching...

[SebastJava]

I tried the steps to reproduce from the OP from @cschreib above. It didn’t work: the file thumbnail was displayed okay, without any bugs. I tried again. It didn’t work, again: it was all okay, no bugs there. Then i tried those extra steps, after having tried all the operations from the OP, and thus still having those new files:

1. Duplicate this plot.eps.
2. Delete the original one.
3. Rename it just like the original: plot (copy).eps -> plot.eps

Next, do as explained before in the OP, again:

1. Go to the parent directory, so you don’t see this plot.eps...
2. Open a terminal in this directory (the one containing test.pro, not the inner one!) and launch the GDL interpreter with the command gdl.
3. Once inside the GDL interpreter, type .r test.pro and press Enter.
4. Open the inner tmp directory... See? No file is displayed and Nemo gets stuck somehow, indefinitely displaying the "loading" cycling arrow in the bottom right corner.

I tried again, again and again. I always end up with this bug as described in the OP.

But this is just an "edge case". I still want to prove this happens, under some specific conditions, when making things as simple as coloured squares... And using only regular software such as Inkscape without any extra module.

[SebastJava]

[SebastJava]

But nobody would do such a duplicate, delete and rename as described in my preceding post.

Here is another thing that is more likely to be done:
(To make it clearer, i replay the whole thing again.)

1. install the package gnudatalanguage if not already done.
2. Copy the code below in a file called test.pro in a directory of your choice.

file_mkdir, 'tmp/'

set_plot, 'ps', /interpolate
device, filename='tmp/plot.eps', xsize=9, ysize=9, /color, /decomposed, /encapsulated, bits_per_pixel=8
!p.background = 'ffffff'x
!p.color = 0

seed = 42
data = randomn(seed, 512, 512)

tv, data

device, /close

end

3. Open a terminal in this directory and launch the GDL interpreter with the command gdl.
4. Once inside the GDL interpreter, type .r test.pro and press Enter.
5. This will create a new directory called tmp, containing the EPS file plot.eps. With nemo, open the tmp directory and see if the file is indeed there. It should work.
6. Say you want to try a second one... In Nemo, select this plot.eps and click Edit > Duplicate. You now have plot.eps and plot (copy).eps.
7. Then with Nemo go to the parent directory, so these plot.eps and plot (copy).eps are not displayed in Nemo anymore.
8. Open this test.pro file in Xed. Replace: plot.eps -> plot (copy).eps. Save. Close.
9. Open a terminal in this parent directory (so you are NOT seeing the EPS files!) and launch the GDL interpreter with the command gdl.
10. Once inside the GDL interpreter, type .r test.pro and press Enter.
11. With Nemo, open the tmp directory and see if the plot (copy).eps got changed. You can’t see it! Nemo failed to generate the thumbnail and it looks like being stuck on an endless loop, but it is just the "Loading..." cycling image that keeps being displayed...

Of course, as soon as you move out of this tmp directory and then back in, things are displayed okay.

This is an edge case. I have other new issues coming soon: simple newbie stuff being done and ending up on missing or outdated thumbnails. Many issues but it is all about the thumbnails for PNG, SVG or other image files.

[SebastJava]

[Jeremy7701]

If you try the above on files which don't have embedded spaces, does it make any difference?

[SebastJava]

@Jeremy7701 You mean with some other filename like "plot-2.eps"? I tried. There was no bug this time. The 2 thumbnails were displayed okay.

I don’t understand. I am currently working on reproducing some other similar issues, but much more simple, just newbie stuff, and i am having the same kind of trouble with thumbnails, and my filename is totally straightforward: "circle.svg". Without spaces or anything weird. Still testing. Not confirmed yet.

But it looks like, on this issue here, removing the space in the filename solved this.

[cschreib]

Could it be the fact of renaming the file, rather than the lack of whitespace? (I assume you manually renamed the file after duplicating it, rather than directly copy the file "plot.eps" into the new file "plot-2.eps")

[SebastJava]

Yes, it could be. I am not sure. Right now i am out of this complex, strange and edge case issue. It was not my issue in the first place. I am currently back to exploring a few different issues all related to thumbnail generation for image files. My issues are all simple, newbie issues. I get this feeling that understanding and solving my simple newbie issues could solve this here as well, later, maybe.

Oh, you mean renaming the file would have solved this? I don’t know. I had a similar issue where renaming the file actually caused similar problems with the thumbnail generation: Thumbnails are not updated when editing SVG files after having renamed them #2621 So i am very confused.

There is also another issue where the steps to reproduce are very different, much more simple, and the result is the same as the one here. Check my brand new one: SVG file "disappears" after editing a copy of it. Endless "Loading" cycling indicator is displayed... #2623

On top of that, since i had an issue with the renaming before, i tried both Nemo Duplicate and Renaming methods and also using the Terminal with cp plot.eps plot-2.eps. This second method did not require any renaming. And, frankly, i am not sure it worked on first try with the Nemo method. I can’t remember. Maybe it didn’t work at first, but then i tried with the Terminal and it worked, and then i tried again with Nemo and this time it worked because of some file memory cache somewhere? I am totally confused.

[SebastJava]

There was another similar issue here: #2736

Hopefully, it got fixed in 73aafd8 and re-adjusted in later commits. This will be in the upcoming Nemo 5.0.

To be re-tested in Nemo 5.0, and possibly closed.