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
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.
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.
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.
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.
All right, I'll look into it.
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.
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.
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.
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 ?
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"
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.
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.
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.
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.
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.
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); } }
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); } }
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...
Created attachment 525 Suggested fix Please try this patch.
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); + }
Right, that was missing a MAX (width,1) and MAX (height,1).
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.
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.