! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Thunar freezes/memleaks when entering dir containing file types it "cannot ha...
Status:
CLOSED: FIXED
Product:
Thunar-vfs
Component:
General

Comments

Description Nikolas.Arend 2006-04-21 20:22:56 CEST
Hi,

Thunar (svn r21138) seems to have a problem with parsing directories which contain files of types it doesn't know how to handle or cannot open the handler. In my case, the directory contained two video files of type .mov (see gdb output below). With these files present, Thunar would freeze and allocate tons of memory (looks like all it can get), apparently being stuck in a loop or s.th. Without the files, Thunar loads the directory just fine.
Please let me know if you need anything else besides the output I attached.

Best,  Nick.


Starting program: /usr/bin/Thunar
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x4c8000
[Thread debugging using libthread_db enabled]
[New Thread -1208572224 (LWP 29627)]
[New Thread -1211278416 (LWP 29630)]
[New Thread -1221768272 (LWP 29631)]
[New Thread -1232258128 (LWP 29632)]
[New Thread -1242752080 (LWP 29633)]
[New Thread -1253241936 (LWP 29634)]
[New Thread -1263731792 (LWP 29635)]
thunar-uca-Message: Initializing ThunarUca extension
[Thread -1232258128 (LWP 29632) exited]
[Thread -1242752080 (LWP 29633) exited]
[Thread -1263731792 (LWP 29635) exited]
thunar-apr-Message: Initializing ThunarApr extension
thunar-sbr-Message: Initializing ThunarSbr extension
thunar-sbr-Message: Shutting down ThunarSbr extension
thunar-apr-Message: Shutting down ThunarApr extension
[Thread -1211278416 (LWP 29630) exited]
[Thread -1221768272 (LWP 29631) exited]
[Thread -1253241936 (LWP 29634) exited]
[New Thread -1253241936 (LWP 29639)]
[New Thread -1221768272 (LWP 29640)]
[Thread -1221768272 (LWP 29640) exited]
[New Thread -1221768272 (LWP 29641)]
Detaching after fork from child process 29642.
[Thread -1253241936 (LWP 29639) exited]

(process:29642): GLib-GObject-WARNING **: gsignal.c:1719: signal `got-redirect' is invalid for instance `0x819cab0'
** Message: don't know how to handle audio/mpeg, mpegversion=(int)4, codec_data=(buffer)1208, rate=(int)44100, channels=(int)1
** Message: don't know how to handle video/mpeg, mpegversion=(int)4, systemstream=(boolean)false, codec_data=(buffer)000001b0f3000001b50ee040c0cf0000010000000120008440fa285020f0a21f, width=(int)320, height=(int)240, framerate=(double)12.5
totem-video-thumbnailer couln't open file 'file:///home/narend/download/Kerry_Insta_Poll.mov'
Reason: There were no decoders found to handle the stream in file "file:///home/narend/download/Kerry_Insta_Poll.mov", you might need to install the corresponding plugins.

GLib-ERROR **: gmem.c:141: failed to allocate 573468672 bytes
aborting...

Program received signal SIGABRT, Aborted.
[Switching to Thread -1221768272 (LWP 29641)]
0x004c8402 in __kernel_vsyscall ()
(gdb) where
#0  0x004c8402 in __kernel_vsyscall ()
#1  0x0050ef90 in raise () from /lib/libc.so.6
#2  0x00510678 in abort () from /lib/libc.so.6
#3  0x0099d3b1 in g_logv () from /usr/lib/libglib-2.0.so.0
#4  0x0099d3e5 in g_log () from /usr/lib/libglib-2.0.so.0
#5  0x0099ab14 in g_malloc () from /usr/lib/libglib-2.0.so.0
#6  0x00a65626 in gdk_pixbuf_rotation_get_type ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
#7  0x00a669b4 in gdk_pixbuf_rotation_get_type ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
#8  0x00a61028 in gdk_pixbuf_scale () from /usr/lib/libgdk_pixbuf-2.0.so.0
#9  0x00a610f8 in gdk_pixbuf_scale_simple ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
#10 0x00e2171f in exo_gdk_pixbuf_scale_ratio () from /usr/lib/libexo-0.3.so.0
#11 0x00cb1bf1 in IA__thunar_vfs_thumb_factory_generate_thumbnail (
    factory=0x9a74120, info=0x988cfd8) at thunar-vfs-thumb.c:687
#12 0x0809d50d in thunar_thumbnail_generator_thread (user_data=0x9a76870)
    at thunar-thumbnail-generator.c:248
#13 0x009afffa in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#14 0x00740bd4 in start_thread () from /lib/libpthread.so.0
#15 0x005b14fe in clone () from /lib/libc.so.6
Comment 1 Benedikt Meurer editbugs 2006-04-22 14:30:08 CEST
That's not Thunar going mad, but the totem-video-thumbnailer launched by Thunar to generate thumbnails for video files. You can file a bug report to totem to have this fixed.
Comment 2 Benedikt Meurer editbugs 2006-04-22 14:32:38 CEST
Sorry. Lacks some explanation: Thunar crashes because the thumbnail generated and saved by totem-video-thumbnailer seems to be invalid (too large), and GdkPixbuf cannot allocate the memory, and terminates the process.
Comment 3 Nikolas.Arend 2006-04-22 14:44:38 CEST
Hm, if I run the command

totem-video-thumbnailer Kerry_Insta_Poll.mov test.png

on the file in question manually, it fails, telling me that it cannot handle the format (like in the gdb output I attached). But it doesn't go mad and obviously does not produce a thumbnail at all. How is totem-video-thumbnailer invoked by Thunar, and how would I disable it?

Nick.
Comment 4 Benedikt Meurer editbugs 2006-04-22 16:53:50 CEST
In thunar-vfs-thumb.c, the gnome_thumbnailer_script_run() runs the command (determine from the GNOME thumbnailer registry using gconf) and returns the pixbuf if the command exited successfully. If the command returns with an exit code != 0, thunar_vfs_thumb_factory_generate_thumbnail() tries to load the file using GdkPixbuf directly, which should fail for .mov files. You can try to insert a debug statement there to see whether GdkPixbuf is the problem.
Comment 5 Nikolas.Arend 2006-04-22 17:36:01 CEST
All right, I'll look into it.
Comment 6 Nikolas.Arend 2006-04-23 12:22:42 CEST
Benedikt,

the problem is not with totem-video-thumbnailer, I can't see any bug here. It exits with status 1, hence a NULL pointer is return by gnome_thumbnailer_script_run(). In thunar_vfs_thumb_factory_generate_thumbnail(), that causes pixbuf to be created by gdk_pixbuf_new_from_file(). The "freeze"/extensive memory allocation actually happens when exo_gdk_pixbuf_scale_ratio() is called. Thunar doesn't crash, but only requires most of the system resources in my case (video of type .mov). I did the debugging on a bigger machine, so I didn't realized that before. Once the exo_gdk_pixbuf_scale_ratio() call is finished and the thumbnail created/scaled, Thunar (and the rest of the system ;-) becomes responsive again.
So you might want to look into exo_gdk_pixbuf_scale_ratio() and what it does with pixbuf's created by gdk_pixbuf_new_from_file().

HTH,   Nick.
Comment 7 Benedikt Meurer editbugs 2006-04-23 13:03:07 CEST
There's the problem: exo_gdk_pixbuf_scale_ratio() is trivial. It's just a wrapper around gdk_pixbuf_scale_simple(). Unless the dimensions of the source pixbuf are totally out-of-range, there should be no problem. But I wonder what kind of GdkPixbuf module do you use that allows to load .mov files?

You can however add a debug statement to exo_gdk_pixbuf_scale_ratio(), printing the source and dest dimensions, that should help to find the cause.
Comment 8 Nikolas.Arend 2006-04-23 16:51:19 CEST
The returned width is 634221, the height 111. Obviously s.th. went wrong when determining the width or creating pixbuf via gdk_pixbuf_new_from_file(). Would it make sense to check the size and only process pixbufs that are within a certain range? I know it's not desirable to implement workarounds for dodgy functions from other libraries, but it's affecting Thunar's usability quite a bit (and that of the whole system, since it'll start to use swap space and throttles the cpu).
There might be a problem with other file types and distros as well, because as far as I remember, I'm still using whatever GdkPixbuf module is shipping with FC4.

Best,  Nick.
Comment 9 Benedikt Meurer editbugs 2006-04-23 16:53:10 CEST
Yep, we defintely need to work-around that. But it still needs to be fixed in Gtk. Can you check which plugin provides the loader using

 gdk-pixbuf-query-loaders

?
Comment 10 Nikolas.Arend 2006-04-23 17:38:23 CEST
I'm a bit at a loss with what gdk-pixbuf-query-loaders-32 tells me. I attached the essentials of its output below, but I'm not sure what loader is used. None seems to really fit.

But I tried gdk_pixbuf_new_from_file_at_scale(path, 128, 128, FALSE, NULL), which returns more reasonable values for width and height in case of the .mov file (width: 748, height: 226 according to gdk_pixbuf_get_width/heigth() ). Thunar behaves normally now and maybe using that instead of gdk_pixbuf_new_from_file() would already suffice. But I'm not sure whether this works for all weird file formats. Maybe an additional check is required?


# GdkPixbuf Image Loader Modules file
# Automatically generated file, do not edit
# Created by gdk-pixbuf-query-loaders from gtk+-2.6.10
#
# LoaderDir = /usr/lib/gtk-2.0/2.4.0/loaders
#
"/usr/lib/gtk-2.0/2.4.0/loaders/svg_loader.so"
"svg" 2 "gtk20" "Scalable Vector Graphics"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-tiff.so"
"tiff" 0 "gtk20" "The TIFF image format"
"image/tiff" ""


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xbm.so"
"xbm" 4 "gtk20" "The XBM image format"
"image/x-xbitmap" ""

"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-wbmp.so"
"wbmp" 4 "gtk20" "The WBMP image format"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-ras.so"
"ras" 4 "gtk20" "The Sun raster image format"

"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so"
"png" 5 "gtk20" "The PNG image format"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-jpeg.so"
"jpeg" 5 "gtk20" "The JPEG image format"

"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-pcx.so"
"pcx" 4 "gtk20" "The PCX image format"

"/usr/lib/gtk-2.0/2.4.0/loaders/io-wmf.so"
"wmf" 0 "gtk20" "Windows Metafile"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-ani.so"
"ani" 4 "gtk20" "The ANI image format"

"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so"
"xpm" 4 "gtk20" "The XPM image format"

"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-tga.so"
"tga" 4 "gtk20" "The Targa image format"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-gif.so"
"gif" 4 "gtk20" "The GIF image format"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-pnm.so"
"pnm" 4 "gtk20" "The PNM/PBM/PGM/PPM image format family"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-ico.so"
"ico" 5 "gtk20" "The ICO image format"


"/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-bmp.so"
"bmp" 5 "gtk20" "The BMP image format"
Comment 11 Nikolas.Arend 2006-04-23 17:42:00 CEST
Ah, and I'm not sure why
gdk_pixbuf_new_from_file_at_scale(path, 128, 128, FALSE, NULL)
returns an pixbuf that is 748 by 226 in size and still needs to be scaled when I requested one of 128 by 128.
Comment 12 Benedikt Meurer editbugs 2006-04-23 18:06:27 CEST
gdk_pixbuf_new_from_file_at_scale() cannot be used as it may scale up small images, which is not what we want. Your loader list looks pretty much standard, and as far as I can see none of these loaders should be able to load .mov files. Strange. I'll try to come up with a work-around.
Comment 13 Nikolas.Arend 2006-04-23 20:50:53 CEST
How about s.th. like

  /* fallback to GdkPixbuf based loading */
  if (G_LIKELY (pixbuf == NULL))
    {
/*        pixbuf = gdk_pixbuf_new_from_file (path, NULL); */
       format = gdk_pixbuf_get_file_info(path, &width, &height);
       if (width > 0 && height > 0)
         {
           gdk_pixbuf_size = (width >= height) ? width : height;
	   gdk_pixbuf_size = (gdk_pixbuf_size > size) ? size : gdk_pixbuf_size;
           pixbuf = gdk_pixbuf_new_from_file_at_scale(path, gdk_pixbuf_size, gdk_pixbuf_size, TRUE, NULL);
	 }
    }

It shouldn't scale up smaller images and seems to work.
Comment 14 Nikolas.Arend 2006-04-23 21:02:30 CEST
Sorry, please ignore the last message. I forgot to test the code on the .mov files. It doesn't work for them, but for all others, though.
Comment 15 Benedikt Meurer editbugs 2006-04-23 21:04:09 CEST
I was thinking of a similar solution, but with a single loader step, and utilizing the mime type to look up the loader, as I'm pretty sure the problem comes from guessing the loader using the data.
Comment 16 Nikolas.Arend 2006-04-23 23:11:04 CEST
Ok, the attached is a wee bit clumsy, but seems to work. gdk_pixbuf_new_from_file() and friends obviously have problems with pictures that feature extreme aspect ratios. (e.g. the JPEG thumbnailer doesn't seem to suffer from this). After passing a width/height of 128/1 to gdk_pixbuf_new_from_file_at_scale() for creating a pixbuf from the .mov file, it again took ages, whereas a ratio of 128/128 for the same file processes reasonably fast.
I assumed a factor of 10 as a ratio limit, but that is arbitrary. I didn't play around with that much.
However, if we could prevent the gdk_pixbuf_new_from_file() from picking the wrong/any loader in the first place, that would be much cleaner. But doesn't the mime-type use file extensions to determine the format? That might be a problem.

Best,  Nick.


/* fallback to GdkPixbuf based loading */
  g_message("Before new_from_file\n");
  if (G_LIKELY (pixbuf == NULL))
    {
/*        pixbuf = gdk_pixbuf_new_from_file (path, NULL); */
       format = gdk_pixbuf_get_file_info(path, &width, &height);
       if (width > 0 && height > 0)
         {
	   if (width >= height && width > size)
	     {
	       if (width > size)
	         {
		   /* Extreme aspect ratios seem to cause a problem with gdk_pixbuf_new_from_file functions */
                   height = (width/height > 10) ? size : (gint) height/((double) width/size) + 1;
	           width = size;
	         }
	     }
	   else
	     {
	       if (height > size)
	         {
                   width = (height/width > 10) ? size : (gint) width/((double) height/size) + 1;
	           height = size;
		 }
             }
           pixbuf = gdk_pixbuf_new_from_file_at_scale(path, width, height, FALSE, NULL);
	 }
    }
Comment 17 Nikolas.Arend 2006-04-23 23:23:38 CEST
Sorry, my bad, it's getting late. Here's what I meant to sent ;-) ...


  /* fallback to GdkPixbuf based loading */
  if (G_LIKELY (pixbuf == NULL))
    {
/*        pixbuf = gdk_pixbuf_new_from_file (path, NULL); */
       format = gdk_pixbuf_get_file_info(path, &width, &height);
       if (width > 0 && height > 0)
         {
	   if (width >= height)
	     {
	       if (width > size)
	         {
		   /* Extreme aspect ratios seem to cause a problem with gdk_pixbuf_new_from_file functions */
                   height = (width/height > 10) ? size : (gint) height/((double) width/size) + 1;
	           width = size;
	         }
	     }
	   else
	     {
	       if (height > size)
	         {
                   width = (height/width > 10) ? size : (gint) width/((double) height/size) + 1;
	           height = size;
		 }
             }
           pixbuf = gdk_pixbuf_new_from_file_at_scale(path, width, height, FALSE, NULL);
	 }
    }
Comment 18 Nikolas.Arend 2006-04-23 23:36:05 CEST
Looks like the call
format = gdk_pixbuf_get_file_info(path, &width, &height);
has a problem with .svg files. It aborts with

librsvg-WARNING **: rsvg_start_svg: width and height not specified in the SVG, nor supplied by the size callback
aborting...

Shouldn't it just return a NULL pointer in that case? I guess that renders the proposed work-around unusable. Ah, well...
Comment 19 Benedikt Meurer editbugs 2006-04-24 14:28:00 CEST
Created attachment 525 
Suggested fix

Please try this patch.
Comment 20 Nikolas.Arend 2006-04-24 15:11:39 CEST
Looks good. The mime-type recognition seems to work as Thunar won't try to create a pixbuf for my .mov files any more.
One thing about the size calculation... Does rint() always round up (for all C libraries on all supported platforms)? Because if hratio or wratio becomes very large (huge picture or bad size information from gdk), the quotient (width / hratio) might become < 0.5, which would result in a zero width/height when rounded down.

+      wratio = (gdouble) width / (gdouble) size;
+      hratio = (gdouble) height / (gdouble) size;
+
+      if (hratio > wratio)
+        {
+          width = rint (width / hratio);
+          height = size;
+        }
+      else
+        {
+          width = size;
+          height = rint (height / wratio);
+        }
Comment 21 Benedikt Meurer editbugs 2006-04-24 17:43:24 CEST
Right, that was missing a MAX (width,1) and MAX (height,1).
Comment 22 Benedikt Meurer editbugs 2006-04-24 17:48:53 CEST
Committed with revision 21209.

2006-04-24	Benedikt Meurer <benny@xfce.org>

	* thunar-vfs/thunar-vfs-thumb-pixbuf.{c,h}, thunar-vfs/Makefile.am,
	  thunar-vfs/thunar-vfs-thumb.c: Improve the GdkPixbuf fallback thumb-
	  nail generator. Bug #1703.

Comment 23 Nikolas.Arend 2006-04-25 19:45:00 CEST
I forgot... thanks very much for creating Thunar! It comes quite close to the way I think a file manager should look'n'feel like. Closer than any other yet.

Best,  Nick.

Bug #1703

Reported by:
Nikolas.Arend
Reported on: 2006-04-21
Last modified on: 2010-11-07

People

Assignee:
Jannis Pohlmann
CC List:
1 user

Version

Version:
unspecified

Attachments

Suggested fix (8.74 KB, patch)
2006-04-24 14:28 CEST , Benedikt Meurer
no flags

Additional information