Bug#967941: nautilus: fails to generate thumbnails for h264 encoded video files

[fred]

Package: nautilus
Version: 3.36.3-1
Severity: normal
X-Debbugs-Cc: con...@666hellfire.club

Dear Maintainer,

Nautilus fails to generate thumbnails for certain video files (h264 encoded
video stream).

Fresh Debian testing (Gnome) installed today. Steps to reproduce :

(sudo apt install youtube-dl)

Using youtube-dl to download some short clips (Nature/scenery samples) :

$ youtube-dl https://www.youtube.com/watch?v=LTvFsTbyILg

webm container, VP9 video encoded : thumbnail will be generated OK


$ youtube-dl https://www.youtube.com/watch?v=l7GX_XII2K0

mkv container, h264 video encoded : thumbnail will not be generated



Both files will play fine with Totem media player


Producing a thumbnail using totem-video-thumbnailer :

$ totem-video-thumbnailer Beautiful\ Nature\ 1080p.-l7GX_XII2K0.mkv Beautiful\
Nature\ 1080p.-l7GX_XII2K0.mkv.png

will produce a thumbnail fine! But not nautilus.




-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nautilus depends on:
ii bubblewrap 0.4.1-1
ii desktop-file-utils 0.26-1
ii gsettings-desktop-schemas 3.36.1-1
ii gvfs 1.44.1-1
ii libatk1.0-0 2.36.0-2
ii libc6 2.31-2
ii libcairo-gobject2 1.16.0-4
ii libcairo2 1.16.0-4
ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii libgexiv2-2 0.12.1-1
ii libglib2.0-0 2.64.4-1
ii libglib2.0-data 2.64.4-1
ii libgnome-autoar-0-0 0.2.4-2
ii libgnome-desktop-3-19 3.36.4-1
ii libgstreamer-plugins-base1.0-0 1.16.2-4
ii libgstreamer1.0-0 1.16.2-2
ii libgtk-3-0 3.24.20-1
ii libnautilus-extension1a 3.36.3-1
ii libpango-1.0-0 1.44.7-4
ii libpangocairo-1.0-0 1.44.7-4
ii libselinux1 3.1-2
ii libtracker-sparql-2.0-0 2.3.4-1+b1
ii nautilus-data 3.36.3-1
ii shared-mime-info 1.15-1
ii tracker 2.3.4-1+b1
ii tracker-extract 2.3.3-2+b1
ii tracker-miner-fs 2.3.3-2+b1

Versions of packages nautilus recommends:
ii gnome-sushi 3.34.0-2
ii gvfs-backends 1.44.1-1
ii librsvg2-common 2.48.7-1

Versions of packages nautilus suggests:
ii eog 3.36.3-1
ii evince [pdf-viewer] 3.36.7-1
ii nautilus-extension-brasero 3.12.2-6
ii nautilus-sendto 3.8.6-3
ii totem 3.34.1-2+b1
ii xdg-user-dirs 0.17-2

-- no debconf information

[fred]

I did update my 2 Debian systems (unstable and testing) today, and the
bug seems to have disappeared / been fixed

All video thumbnails are generated properly in nautilus now.

[Simon McVittie]

Control: reassign 967941 libopenblas0-pthread 0.3.10+ds-2
Control: affects 967941 + nautilus totem

On Thu, 22 Oct 2020 at 21:31:41 +0200, Thorsten Ehlers wrote:
> So I dug a little bit deeper into this bug

Please include some context in replies to bugs: package maintainers will
usually see your messages out of context.

For the libopenblas0-pthread maintainers: the original bug report is that
h.264 video files were not thumbnailed successfully by GNOME's Nautilus
file manager. The actual thumbnailing is delegated to
totem-video-thumbnailer, from the totem package.

I can reproduce this with the sample videos from the original bug report
after installing libopenblas0-pthread. After removing libopenblas0-pthread,
the alternative switches to /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3
and the thumbnailer works again.

Steps to reproduce:

$ sudo apt install totem libopenblas0-pthread youtube-dl
$ youtube-dl https://www.youtube.com/watch?v=LTvFsTbyILg
$ youtube-dl https://www.youtube.com/watch?v=l7GX_XII2K0
$ totem-video-thumbnailer -v Yosemite\ Nature\ Drone\ Video-LTvFsTbyILg.webm tmp.png
(succeeds)
$ totem-video-thumbnailer -v Beautiful\ Nature\ 1080p.-l7GX_XII2K0.mkv tmp.png

Output:

TotemVideoThumbnailer-Message: 22:02:21.412: Initialised libraries, about to create video widget
TotemVideoThumbnailer-Message: 22:02:21.436: setting URI file:///home/smcv/tmp/Beautiful%20Nature%201080p.-l7GX_XII2K0.mkv
TotemVideoThumbnailer-Message: 22:02:21.437: Video widget created
TotemVideoThumbnailer-Message: 22:02:21.437: About to open video file
TotemVideoThumbnailer-Message: 22:02:21.713: Checking whether file has cover
TotemVideoThumbnailer-Message: 22:02:21.713: Opened video file: 'Beautiful Nature 1080p.-l7GX_XII2K0.mkv'
TotemVideoThumbnailer-Message: 22:02:21.713: About to seek to 0.333333
TotemVideoThumbnailer-Message: 22:02:21.757: About to get frame for iter 0

(totem-video-thumbnailer:98347): GStreamer-WARNING **: 22:02:21.758: failed to create thread: Error creating thread: Resource temporarily unavailable

(totem-video-thumbnailer:98347): GLib-ERROR **: 22:02:21.763: ../../../glib/gmem.c:112: failed to allocate 3145167 bytes
[1] 98347 trace trap (core dumped) totem-video-thumbnailer -v Beautiful\ Nature\ 1080p.-l7GX_XII2K0.mkv tmp.png

> and in my case it turned out
> the real problem is libopenblas0-pthread version 0.3.10+ds-2 and -3.
>
> This package is a dependency of libopenblas0 which is a dependency of Octave and others.
>
> Creating a thumbnail with totem-video-thumbnailer fails for flv and mkv videos like that one mentioned by the OP:
>
> (totem-video-thumbnailer:37500): GStreamer-WARNING **: 21:23:41.129: failed to create thread: Error creating thread: Die Ressource ist zur Zeit nicht verfügbar
>
> (totem-video-thumbnailer:37500): GLib-ERROR **: 21:23:41.131: ../../../glib/gmem.c:112: failed to allocate 3145167 bytes
> Trace/Breakpoint ausgelöst
>
> Installing libopenblas0-pthread_0.3.10+ds-1 or adding the -l option in /usr/share/thumbnailers/totem.thumbnailer works
> around this bug.

The -l option is documented to disable the time limit for thumbnail
generation (the default is that totem-video-thumbnailer gives up after
30 seconds). This is implemented as a watchdog thread.

Perhaps the watchdog thread and whatever threads are used by
libopenblas0-pthread, together, are enough to exceed a memory limit?
totem seems to set its RLIMIT_DATA to 512M plus the size of the file.

smcv

[Bernhard Übelacker]

Dear Maintainer,
I was trying to collect some more information for bug #973811.
There it looks like openblas does its own memory management seems
therefore affected by some sandboxing disallowing a SYS_bind syscall.

With the test VM I used there I get with current testing this
output for a manually created test mkv with h264 video the
following output.

This is now kind of different, but might be caused by some
new package versions since last October.
Therefore I am not sure if this is really what I observe.

It seems like openblas tries the allocators in variable memoryalloc,
and if no one works calls the terminating null pointer with
the current version.

Kind regards,
Bernhard



# ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 -vcodec h264 -acodec libvorbis output.mkv

benutzer@debian:~$ totem-video-thumbnailer -v output.mkv tmp.png
TotemVideoThumbnailer-Message: 17:37:58.702: Initialised libraries, about to create video widget
TotemVideoThumbnailer-Message: 17:37:58.710: setting URI file:///home/benutzer/output.mkv
TotemVideoThumbnailer-Message: 17:37:58.710: Video widget created
TotemVideoThumbnailer-Message: 17:37:58.710: About to open video file
OpenBLAS blas_thread_init: pthread_create failed for thread 6 of 16: Die Ressource ist zur Zeit nicht verfügbar
OpenBLAS blas_thread_init: RLIMIT_NPROC 11759 current, 11759 max
Speicherzugriffsfehler (Speicherabzug geschrieben)

benutzer@debian:~$ coredumpctl -q list
TIME PID UID GID SIG COREFILE EXE
Wed 2021-04-07 17:37:59 CEST 3087 1000 1000 11 present /usr/bin/totem-video-thumbnailer

benutzer@debian:~$ coredumpctl -q gdb 3087
PID: 3087 (totem-video-thu)
UID: 1000 (benutzer)
GID: 1000 (benutzer)
Signal: 11 (SEGV)
Timestamp: Wed 2021-04-07 17:37:58 CEST (7min ago)
Command Line: totem-video-thumbnailer -v output.mkv tmp.png
Executable: /usr/bin/totem-video-thumbnailer
Control Group: /user.slice/user-1000.slice/session-8.scope
Unit: session-8.scope
Slice: user-1000.slice
Session: 8
Owner UID: 1000 (benutzer)
Boot ID: 505eeb0b4fe548338077ab20802215cc
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
Hostname: debian
Storage: /var/lib/systemd/coredump/core.totem-video-thu.1000.505eeb0b4fe548338077ab20802215cc.3087.1617809878000000.zst
Message: Process 3087 (totem-video-thu) of user 1000 dumped core.

Stack trace of thread 3096:
#0 0x0000000000000000 n/a (n/a + 0x0)

...
Core was generated by `totem-video-thumbnailer -v output.mkv tmp.png'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000000000 in ?? ()
[Current thread is 1 (Thread 0x7f4ab3aa6700 (LWP 3096))]
(gdb) bt
#0 0x0000000000000000 in ()
#1 0x00007f4ab5364709 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
#2 0x00007f4ab5364f04 in blas_thread_server (arg=<optimized out>) at blas_server.c:366
#3 0x00007f4ade5deea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#4 0x00007f4adebdadef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) cd /home/benutzer/source/libopenblas0-pthread/orig/openblas-0.3.13+ds/driver/others
Working directory /home/benutzer/source/libopenblas0-pthread/orig/openblas-0.3.13+ds/driver/others.
(gdb) up
#1 0x00007f4ab5364709 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
2793 map_address = (*func)((void *)base_address);
(gdb) print memoryalloc
$1 = {0x7f4ab5364230 <alloc_mmap>, 0x7f4ab53641d0 <alloc_malloc>, 0x0}

[Bernhard Übelacker]

Dear Maintainer,
I wondered why the first two allocators would fail
and tried to step into.

At least the alloc_malloc seems to use the
regular glibc-malloc, and should succeed therefore [1]?

So might there be a size restriction in place how much memory
totem-video-thumbnailer is allowed to allocate.

Because each of these threads seems to try to allocate 128 MB,
but malloc returns 0.

And such a totem-video-thumbnailer process seems to contain
many threads [2]. (One for each core?)


Kind regards,
Bernhard


[1]
(gdb) bt
#0 0x00007ffff79390f7 in __GI___libc_malloc (bytes=134221824) at malloc.c:3023
#1 0x00007fffce1331de in alloc_malloc (address=<optimized out>) at memory.c:2290
#2 0x00007fffce133709 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793

Thread 8 "matroskademux0:" hit Breakpoint 4, alloc_malloc (address=0x0) at memory.c:2290
2290 map_address = (void *)malloc(BUFFER_SIZE + FIXED_PAGESIZE);


[2]
...
6 Thread 0x7ffff1ef0700 (LWP 3797) "matroskademux0:" libc_feholdsetround_sse_ctx (r=0, ctx=<synthetic pointer>) at ../sysdeps/x86/fpu/fenv_private.h:416
7 Thread 0x7ffff16ef700 (LWP 3798) "multiqueue0:src" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
8 Thread 0x7fffcd877700 (LWP 3799) "matroskademux0:" 0x00007ffff7993fa7 in sched_yield () at ../sysdeps/unix/syscall-template.S:120
* 9 Thread 0x7fffcd076700 (LWP 3800) "matroskademux0:" 0x0000000000000000 in ?? ()
10 Thread 0x7fffcc875700 (LWP 3801) "matroskademux0:" 0x00007ffff7993fa7 in sched_yield () at ../sysdeps/unix/syscall-template.S:120
11 Thread 0x7fffcc074700 (LWP 3802) "matroskademux0:" 0x00007fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
12 Thread 0x7fffcb873700 (LWP 3803) "matroskademux0:" 0x00007fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
13 Thread 0x7fffcb072700 (LWP 3804) "matroskademux0:" 0x00007fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
14 Thread 0x7fffca871700 (LWP 3805) "matroskademux0:" 0x00007fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
15 Thread 0x7fffc2070700 (LWP 3806) "matroskademux0:" 0x00007fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
16 Thread 0x7fffc186f700 (LWP 3807) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290
17 Thread 0x7fffb906e700 (LWP 3808) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290
18 Thread 0x7fffb886d700 (LWP 3809) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290
19 Thread 0x7fffb806c700 (LWP 3810) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290
20 Thread 0x7fffb786b700 (LWP 3811) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290
21 Thread 0x7fffb706a700 (LWP 3812) "matroskademux0:" 0x00007fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
22 Thread 0x7fffb6869700 (LWP 3813) "matroskademux0:" 0x00007fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793

[Simon McVittie]

On Wed, 07 Apr 2021 at 17:55:14 +0200, Bernhard Übelacker wrote:
> It seems like openblas tries the allocators in variable memoryalloc,
> and if no one works calls the terminating null pointer with
> the current version.

That seems like a bug on its own. If OpenBLAS is not designed to
handle out-of-memory situations (similar to GLib, where g_malloc()
either succeeds or aborts the program) then I would expect a minimal
implementation to look something like this:

while ((func != NULL) && (map_address == (void *) -1)) {
...
}

+ if (map_address == (void *)-1) {
+ fprintf(stderr, "OpenBLAS error: Out of memory\n");
+ abort();
+ }
+
#ifdef DEBUG
printf (" Success -> %08lx\n", map_address);
#endif

Or if it's meant to handle out-of-memory (like e.g. glibc and libdbus),
then it should signal an error to its caller, and each layer of the call
stack will have to handle that error suitably, the same as it would do
if it was using plain malloc().

On Thu, 08 Apr 2021 at 12:01:51 +0200, Bernhard Übelacker wrote:
> At least the alloc_malloc seems to use the
> regular glibc-malloc, and should succeed therefore [1]?
>
> So might there be a size restriction in place how much memory
> totem-video-thumbnailer is allowed to allocate.
>
> Because each of these threads seems to try to allocate 128 MB,
> but malloc returns 0.
>
> And such a totem-video-thumbnailer process seems to contain
> many threads [2]. (One for each core?)

totem-video-thumbnailer sets a resource limit (currently hard-coded to
512M of RLIMIT_DATA and 15 seconds of RLIMIT_CPU) to avoid a runaway
thumbnailing process consuming disproportionate system resources. If
OpenBLAS tries to allocate 128M per thread, then you can't have a
4th thread within that limit.

If totem-video-thumbnailer was directly using OpenBLAS, then it could
presumably ask OpenBLAS to allocate less memory or to limit its number
of threads - but this is happening via arbitrary GStreamer plugins, so
that unfortunately isn't really an option.

smcv

[Stephan Verbücheln]

This bug appears back some time ago. For some months, video thumbnails
failed to generate on multiple of my machines. Since then, I was trying
to figure out the cause.

It only seemed to affect h264, but not all videos were affected. I even
had multiple videos saved from Youtube, some were generating
thumbnails, others were not. I could not find any difference in the
codec parameters.

Adding the -l option in /usr/share/thumbnailers/totem.thumbnailer
worked to prevent this bug. Does this option have any downsides?

Regards

[Bernhard Übelacker]

Hello,
it looks like this option makes it not setting the process limits [1] [2].

Simon wrote it that way before:
totem-video-thumbnailer sets a resource limit ... to avoid a runaway

thumbnailing process consuming disproportionate system resources.

Kind regards,
Bernhard

[1] https://sources.debian.org/src/totem/43.0-2/src/totem-video-thumbnailer.c/#L587
587 { "no-limit", 'l', G_OPTION_FLAG_REVERSE, G_OPTION_ARG_NONE, &time_limit, "Don't limit the thumbnailing time to 30 seconds", NULL },

[2] https://sources.debian.org/src/totem/43.0-2/src/totem-resources.c/?hl=111#L111

[fred]

Still encountering this annoying bug on my testing (trixie) system
(main computer)

However I am unable to remove the libopenblas0-pthread:amd64 0.3.23+ds-
2 package without destroying my operating system (too many programs
depend on it)

so I use the "-l" thumbnailer option workaround as mentioned earlier in
this thread, which works.

I also confirm that the bug is not found in a vanilla Gnome desktop
Debian 12 installation.

Greetings

Fred.