Bug 588039
| Summary: | [abrt] crash in gthumb-2.11.3-1.fc13: Process /usr/bin/gthumb was killed by signal 6 (SIGABRT) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christoph Wickert <christoph.wickert> | ||||
| Component: | gthumb | Assignee: | Christian Krause <chkr> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 13 | CC: | ageha666, alex, behdad, benjavalero, benoit.alary, bloch, bugzilla, bugzilla, chucka, ckteo88, corbet, daviddoria, edi, eduardonunesp, evlyons, eyeneeserver, fedora, ian.springer, jan.kratochvil, jogood, johnmargaritopoulos, ken, kloutvor, laurenthoudijk, marbolangos, michel, mjc, mray271, nuno.dias, oo_0987654321, p_s_oberoi, rvokal, steevithak, tcpip4000, telpelass, tim.liim, vassieux, walter.klammer, wd8oqx, whpgf, wlplqlw | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | abrt_hash:dbd6ed4debce4bc81914c4aece333e58877773a8 | ||||||
| Fixed In Version: | gthumb-2.11.5-1.fc13 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-07-27 02:40:04 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Christoph Wickert
2010-05-02 10:40:49 UTC
Created attachment 410778 [details]
File: backtrace
On the console I see $ gthumb failed to create drawable ** ERROR **: Unable to initialize GtkClutter aborting... <metoo> Any attempt to run gthumb just yields the message shown above. This is Rawhide 64-bit, with gthumb-2.11.3-1.fc14.x86_64. *** Bug 584509 has been marked as a duplicate of this bug. *** *** Bug 590930 has been marked as a duplicate of this bug. *** *** Bug 595960 has been marked as a duplicate of this bug. *** *** Bug 596854 has been marked as a duplicate of this bug. *** *** Bug 597255 has been marked as a duplicate of this bug. *** *** Bug 597299 has been marked as a duplicate of this bug. *** *** Bug 597572 has been marked as a duplicate of this bug. *** *** Bug 597817 has been marked as a duplicate of this bug. *** I have a Nvidia card and I'm using the Nouveau driver. In my case, installing the package 'mesa-dri-drivers-experimental' has solved this issue. The duplicates happen with 32-bit, not only with 64. Installing 'mesa-dri-drivers-experimental' solved the problem here too -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Same here for the mesa-dri-drivers-experimental solution... There are still some warning while loading : $ gthumb (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_ellipsize: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_angle: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkMisc' (gthumb:29021): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_ellipsize: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_angle: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkMisc' (gthumb:29021): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_ellipsize: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_angle: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkMisc' (gthumb:29021): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_ellipsize: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkLabel' (gthumb:29021): Gtk-CRITICAL **: gtk_label_set_angle: assertion `GTK_IS_LABEL (label)' failed (gthumb:29021): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkMisc' (gthumb:29021): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed I think I'm seeing this same bug. I installed Gthumb to replace the crappy "shotwell" thing that came with F13 but when I try to start Gthumb, it crashes silently, followed a few seconds later by one of two things: 1) abrt briefly appears and then crashes itself or 2) abrt appears and says Gthumb crashed but won't let me report it due to a "bad trace" When I look in /var/log/messages I see this: Jun 2 00:21:04 triffid abrt[3716]: saved core dump of pid 3715 (/usr/bin/gthumb) to /var/cache/abrt/ccpp-1275455949-3715.new/coredump (2892963840 bytes) Jun 2 00:21:04 triffid abrtd: Directory 'ccpp-1275455949-3715' creation detected Jun 2 00:21:04 triffid abrt[3716]: size of '/var/cache/abrt' >= 1250 MB, deleting 'ccpp-1275455949-3715' Jun 2 00:21:04 triffid abrt[3716]: Lock file '/var/cache/abrt/ccpp-1275455949-3715.lock' is locked by process 1309 Jun 2 00:21:06 triffid abrtd: '/var/cache/abrt/ccpp-1275455949-3715' does not exist Jun 2 00:21:06 triffid abrtd: Corrupted or bad crash /var/cache/abrt/ccpp-1275455949-3715 (res:1), deleting I'm running an up-to-date Fedora 13 on a Dell Inspiron 8600 laptop. Gthumb worked great on F12, F11, F10, etc. This is the first time I've seen any problems running Gthumb on Fedora on this box. Your case seems different, because your laptop has an ATI card. It seems that the problem in this particular crash is that Gthumb in F13 depends on CLutter for the slideshow, but on Nvidia cards Clutter needs installed the experimental mesa drivers and crashes if not. If this is really the problem, it should be solved or at least added to Common Bugs, although Gthumb is not installed by default. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Actually, my Dell Inspiron 8600 laptop has an nVidia card: nVidia Corporation NV34M [GeForce FX Go5200 64M](rev a1). What is the "clutter" thing that needs to be installed? I did a "yum list clutter*" but got a whole page full of stuff, so I'm not sure what to install. Here is the installed files in my laptop: # yum list installed | grep clutter clutter.x86_64 1.2.8-1.fc13 @updates clutter-gtk.x86_64 0.10.4-1.fc13 @fedora Ok, thanks, looks like that wasn't the problem. RPM shows those two packages as already installed: rpm -q clutter: clutter-1.2.8-1.fc13.i686 rpm -q clutter-gtk: clutter-gtk-0.10.4-1.fc13.i686 What about the "experimental mesa drivers" mentioned in comment 18? Should I try installing those (and if so, what's the package name) ? The package for 3D support in Nvidia cards (with Nouveau) is mesa-dri-drivers-experimental. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Cool, that fixed it! After installing mesa-dri-drivers-experimental, gthumb loads without crashing. I guess the next obvious question is why would gthumb require 3d graphics acceleration to display 2D photos? Aside from the apparent dependency bug in the gthumb package that doesn't let yum/rpm know it needs the mesa drivers, is there a bug in gthumb itself? It seems bizarre that it should even need 3d, much less crash when it's not available? (In reply to comment #23) > Cool, that fixed it! After installing mesa-dri-drivers-experimental, gthumb > loads without crashing. I guess the next obvious question is why would gthumb > require 3d graphics acceleration to display 2D photos? Aside from the apparent > dependency bug in the gthumb package that doesn't let yum/rpm know it needs the > mesa drivers, is there a bug in gthumb itself? It seems bizarre that it should > even need 3d, much less crash when it's not available? You should read the previous posts :D Gthumb uses Clutter for the slideshow, but it should work without 3D, or at least disabled the 3D transitions. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Ok, understood. I didn't realize they'd added fancy 3D stuff to the slide show. So would it make sense to file a separate bug upstream on Gthumb for "not properly detecting whether 3D support is present" or something along those lines? Or does this bug pretty much cover it? well, i'm using neither ATI nor nVidia card cuz i have Fedora 13 installed as a guest on VMWare Server 2.0.0.2643. i've tried mesa-dri-drivers-experimental and it didn't work. I am not sure, but perhaps you need to install the additions or something like this in order to allow VMWare to do some 3D. i think VMWare Server doesn't support 3D acceleration in guests. oh well, i'll just switch to Shotwell then. *** Bug 598244 has been marked as a duplicate of this bug. *** Package: gthumb-2.11.3-1.fc13 Architecture: x86_64 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1.Open an image from desktop folder Comment ----- Opening a png image from desktop folder gives this crash. Juan, if you open Gthumb from the Applications menu it doesn't crash? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #31) > Juan, if you open Gthumb from the Applications menu it doesn't crash? > Yes, it crash also. > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers Juan, try to install the package mesa-dri-drivers-experimental, as said in comment 22 as a possible workaround. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Package: gthumb-2.11.3-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. run 'gthumb .' or 'gthumb image.png' FWIW, the mesa-dri-drivers-experimental fix does not work for me. I'm running basic Intel graphics. I'm also running custom kernels, of course, so maybe I've configured out something important. Before anybody asks: stock kernels don't currently boot on this system for reasons I intend to track down once I've recovered a bit from recent travel. Package: gthumb-2.11.3-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1.just opening the program 2. 3. Package: gthumb-2.11.3-1.fc13 Architecture: i686 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. while start 2. 3. Filed in GNOME Bugzilla (and this bug also get mentioned in LWN -- it appears Jon Corbet is also affected: http://lwn.net/Articles/392261/) This is fixed upstream, and the fix will appear in gThumb 2.11.4 (due to be released Monday June 28). Slideshow functionality should degrade gracefully if clutter is not usable. As a side note: the old slideshow code was horrible to look at, hard to understand, and prone to odd effects (with dual display systems, for example). The new clutter-based code is very clean and elegant, due to clutter's easy-to-use API. That is why clutter was used, not because gThumb will be displaying 3D images or holograms or whatever. - Mike Package: gthumb-2.11.3-1.fc13 Architecture: x86_64 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1.Connect Sony Ericsson J10i 2.launch gthumb 3. Re: Comment #39 Michael, Is there any workaround before we get gthumb 2.11.4 in F13? Thanks. I installed mesa-dri-drivers-experimental but apparently it does not help; gthumb still core dumps. I have 01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) which is neither ATI or nVidia. gthumb-2.11.5-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gthumb-2.11.5-1.fc13 I've not heard from Behdad, so since there's been two releases in which this bug is fixed upstream, I'm pushing an update. Please test and vote up the package above if it fixes the issue for you. It works on my computer, which since it has an ATi Evergreen card, is not supported even with the experimental DRI drivers. *** Bug 608215 has been marked as a duplicate of this bug. *** *** Bug 608581 has been marked as a duplicate of this bug. *** *** Bug 608633 has been marked as a duplicate of this bug. *** *** Bug 606255 has been marked as a duplicate of this bug. *** *** Bug 606491 has been marked as a duplicate of this bug. *** *** Bug 609708 has been marked as a duplicate of this bug. *** *** Bug 613925 has been marked as a duplicate of this bug. *** *** Bug 614203 has been marked as a duplicate of this bug. *** *** Bug 613505 has been marked as a duplicate of this bug. *** *** Bug 613503 has been marked as a duplicate of this bug. *** *** Bug 607786 has been marked as a duplicate of this bug. *** *** Bug 604256 has been marked as a duplicate of this bug. *** *** Bug 604975 has been marked as a duplicate of this bug. *** *** Bug 606135 has been marked as a duplicate of this bug. *** *** Bug 607846 has been marked as a duplicate of this bug. *** *** Bug 611286 has been marked as a duplicate of this bug. *** *** Bug 612037 has been marked as a duplicate of this bug. *** *** Bug 612038 has been marked as a duplicate of this bug. *** *** Bug 612377 has been marked as a duplicate of this bug. *** *** Bug 602615 has been marked as a duplicate of this bug. *** This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Re: Comment #42 Michel, Please advise how to update gthumb for test. I tried this just now: [root@taiwan ~]# rpm -qf /usr/bin/gthumb gthumb-2.11.3-1.fc13.i686 [root@taiwan ~]# yum update --enablerepo=updates-testing gthumb Loaded plugins: presto, refresh-packagekit Setting up Update Process No Packages marked for Update [root@taiwan ~]# date Sun Jul 18 23:48:53 EDT 2010 Did I miss anything? Thanks! I tried the mesa- and clutter-gtk workarounds then I found Comment 65 and entered the yum update ... given, and it found version 2.11.5 which works just fine. Thanks, guys. After the update, I can't determine the problem any more. Thx a lot! ;-) 2.11.5 works, thx! Re: Comment #66 John, Thanks for info. I tried the same yum update ... last night, and it worked this time. Apparently 2.11.5 reached update-testing repo between 7/18 and 7/22. Yes, it worked! Right before update, gthumb-2.11.3-1.fc13.i686 still had core dump immediately after start. After update, no more core dump, BUT now 2.11.5-1 got stuck (for >8 hours) in the "Loading..." stage in one of my directories. Well, that will be addressed in another bug. For now, no more core dump! I added the worked comment to the page pointed to in Comment #42. *** Bug 618012 has been marked as a duplicate of this bug. *** *** Bug 617080 has been marked as a duplicate of this bug. *** *** Bug 615638 has been marked as a duplicate of this bug. *** gthumb-2.11.5-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. *** Bug 618605 has been marked as a duplicate of this bug. *** |