GNOME Bugzilla – Bug 655751
totem crashed with SIGSEGV in g_type_name()
Last modified: 2011-08-10 18:30:37 UTC
this report has been filed here: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/816740 totem is crashing when open it or just open some files with it: ".
+ Trace 227988
Thread 1 (Thread 4972)
Would it be possible to get a backtrace with libpeas' debug symbols installed? Also, can the reporters please try disabling all their Totem plugins[1] and re-enabling them one-by-one to see if it's a specific plugin which is causing the crash? Thanks. [1]: Edit the active-plugins key of the org.gnome.Totem GSettings schema.
Created attachment 193023 [details] totem --debug
I am the reporter. I installed libpeas-dev package, I hope it contains debug symbols. Installed plugins: ~# gsettings get org.gnome.totem active-plugins ['skipto', 'chapters', 'screenshot', 'media_player_keys', 'screensaver', 'movie-properties', 'save-file', 'youtube'] Disabling plugins: ~# gsettings set org.gnome.totem active-plugins [] Totem still crashes.
(In reply to comment #3) > I am the reporter. > > I installed libpeas-dev package, I hope it contains debug symbols. Attachment #193023 [details] isn't a backtrace. To get a backtrace, you need to run Totem inside gdb, as described here: https://live.gnome.org/GettingTraces/Details Basically, you need to run the following commands: gdb totem run (Reproduce the crash) t a a bt (Copy the full backtrace to a new comment on this bug report) Thanks!
Created attachment 193106 [details] gdb backtrace #1 If you'd like to view the other two files let me know.
Actually there is no crash. Totem is in a loop and just shades. It doesn't open a file when it's open because it's unresponsive. After running a while gdb outputs the segfault message. If you click on a video file to open it with totem it just disappears.
(In reply to comment #5) > Created an attachment (id=193106) [details] > gdb backtrace #1 > > If you'd like to view the other two files let me know. That backtrace is less useful than the first. Please make sure you have the debug symbols installed for GLib, GIR and libpeas. Thanks. (In reply to comment #6) > Actually there is no crash. Totem is in a loop and just shades. It doesn't open > a file when it's open because it's unresponsive. After running a while gdb > outputs the segfault message. If gdb is outputting a segfault message then Totem is crashing.
Created attachment 193119 [details] Backtrace(Lacking libpeas-dbg) I have a very hard time finding the debug package for libpeas, but I installed the ones for libgir and glib, and ran the backtrace. Like sam_ describes, when opening totem without asking it to open a video file, it shades and hangs, and gdb outputs the segfult message after a little while. Totem keeps hanging around 'till you quit GDB.
Comment on attachment 193119 [details] Backtrace(Lacking libpeas-dbg) I have a very hard time finding the debug package for libpeas, but I installed the ones for libgir and glib, and ran the backtrace. Like sam_ describes, when opening totem without asking it to open a video file, it shades and hangs, and gdb outputs the segfault message after a little while. Totem keeps hanging around 'till you quit GDB.
(In reply to comment #8) > Created an attachment (id=193119) [details] > Backtrace(Lacking libpeas-dbg) > > I have a very hard time finding the debug package for libpeas, but I installed > the ones for libgir and glib, and ran the backtrace. > > Like sam_ describes, when opening totem without asking it to open a video file, > it shades and hangs, and gdb outputs the segfult message after a little while. > Totem keeps hanging around 'till you quit GDB. Again, that backtrace is mostly missing. There should be about 35 frames in there, each with symbol information (not a message saying “No symbol table info available”).
Created attachment 193241 [details] backtrace
I'm seeing this too: in the current Ubuntu Oneiric build, totem crashes on startup, even when I've disabled all plugins as suggested above. I've attached a backtrace generated with all the necessary debug symbols installed.
(In reply to comment #11) > Created an attachment (id=193241) [details] > backtrace That's a good backtrace, thanks. Would you mind disabling all your plugins (as per comment #1) and re-enabling them one-by-one to see if it's a specific plugin which is causing the crash? If Totem continues to crash with all your plugins disabled, could you get a backtrace of that crash as well and attach it here please. Separately (i.e. with all your original plugins enabled), would you mind running Totem with the following command: PEAS_DEBUG=1 totem and attaching the log here? There's no need to get a backtrace for this one. Thanks!
I tried totem in fedora and I don't get this crash.
I created backtrace (I hope it useful). When I renamed /usr/lib/totem/plugins directory to plugins2, totem worked well. It's interesting because plugins disabled in gsettings.
Created attachment 193278 [details] gdb backtrace
Created attachment 193279 [details] Peas debug
OK, I've just checked all the plugins by removing them out of the plugins directory and then restoring them one by one. These caused totem crash in my case: properties media-player-keys chapters save-file screensaver screenshot youtube
Created attachment 193295 [details] PEAS_DEBUG=1 totem with all plugins in place
Could you please attach your traces as text files rather than binary files?
Could you please give us the versions of totem, libpeas, gir-1.2-totem-1.0 and gir-1.2-peas-1.0 you have installed? Especially, please ensure the versions of the gir package and the bare package match.
totem 3.0.1 libpeas 1.1.1 gir1.2-peas-1.0 1.1.1 gir1.2-totem-1.0 3.0.1
(In reply to comment #22) > totem 3.0.1 > libpeas 1.1.1 > gir1.2-peas-1.0 1.1.1 > gir1.2-totem-1.0 3.0.1 Can you please try either: • downgrading your version of libpeas to 1.0.x; or • upgrading your version of Totem to 3.1.x. There were some API changes/deprecations between libpeas 1.0.x and 1.1.x which are most likely what's causing the problem. Totem 3.1.x has adapted to them, but 3.0.x has not. Thanks.
Do you have plans on pushing v 3.1 to Ubuntu oneiric alpha any time soon?
(In reply to comment #24) > Do you have plans on pushing v 3.1 to Ubuntu oneiric alpha any time soon? That's entirely up to the Ubuntu packagers, and nothing to do with Totem upstream. We made a 3.1.4 tarball release 4 days ago which could be packaged.
Well even with the deprecated stuff, I'd say it's a bug if older programs don't work anymore. There might be a bug in the way deprecated functions have been reimplemented. Looking at the stacktrace it might be a bug in the "new" peas_extension_call().
Created attachment 193516 [details] [review] Fix for libpeas 64-bit-cleanness bug This is not a bug in totem, but in libpeas. libpeas 1.1.1 includes code which is incorrectly casting a pointer to an integer and returning it from a function declared with a return type of GType. A GType is not an unsigned integer! It's an unsigned *long*, and the difference is critical on 64-bit systems as an unsigned long is large enough to hold a pointer and an unsigned integer is not. The attached patch corrects this issue, solving the totem segfaults on x86_64 installs. I would be interested in knowing why the author of this code wrote it the way he did, because this *specific* error in gobject type handling is, in my experience, the single most common 64-bit problem that occurs in GNOME code. I don't believe developers are all independently arriving at the same wrong conclusion about how to write gobjects, so I suspect somewhere out there is some documentation telling people to do it wrong. I would love to track down this wrong documentation and set it on fire. :)
Steve, that's a good catch. I think the issue is missing GPOINTER_TO_GTYPE and GTYPE_TO_POINTER macros in GLib, because developers have been told to use the macros instead of casts and GType is a typedef so it tricks developers used to x86 and not owning a newer x86_64 machine ;-)
Review of attachment 193516 [details] [review]: This patch looks good, but shouldn't you also change the way the data is set? (line 151 in loaders/c/peas-plugin-loader-c.c) Also could you please attach your patch in git-diff format so I can apply it and you get credits? Please give a meaningful commit message as well. Thank you.
Created attachment 193568 [details] [review] updated patch in git-diff format Hi Steve, Updated patch attached in git-diff format. Commit message following the standard git conventions, let me know if there's anything else you need there as far as formatting (is there a convention for including references to GNOME bug #s?) As for setting the data, the GUINT_TO_GPOINTER macro happens to be safe (because it never casts to a guint, only to a gulong). I have no opinion on whether you should avoid the macro here.
Review of attachment 193568 [details] [review]: Still missing the g_object_set_data cast?
It's not "missing"; as I said, I have no opinion on whether the macro use should remain in the setting case. I can certainly replace it with a cast if that's what's wanted.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.