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

Simon McVittie smcv at debian.org
Thu Apr 8 11:32:11 BST 2021


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



More information about the debian-science-maintainers mailing list