GNOME Bugzilla – Bug 732430
Rhythmbox crashes when calling siddec
Last modified: 2016-02-22 00:04:51 UTC
Created attachment 279539 [details] GDB trace When trying to play a SID (C64) file in Rhythmbox, the app crashes. Debugging tends to indicate this is a Gstreamer problem, though I cannot reproduce it with gst-launch. Running gst-launch-1.0 filesrc location=Star_Trekkin.sid ! siddec ! pulsesink will play the file properly. Running rhythmbox Star_Trekkin.sid gives (rhythmbox:9287): Gtk-CRITICAL **: gtk_css_provider_load_from_path: assertion 'path != NULL' failed (rhythmbox:9287): GLib-GObject-CRITICAL **: object SoupServer 0x7f85a4003770 finalized while still in-construction (rhythmbox:9287): GLib-GObject-CRITICAL **: Custom constructor for class SoupServer returned NULL (which is invalid). Please use GInitable instead. (rhythmbox:9287): Gtk-CRITICAL **: gtk_builder_get_object: assertion 'GTK_IS_BUILDER (builder)' failed (rhythmbox:9287): Gtk-CRITICAL **: gtk_builder_get_object: assertion 'GTK_IS_BUILDER (builder)' failed (rhythmbox:9287): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (rhythmbox:9287): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed (rhythmbox:9287): libdmapsharing-WARNING **: DACP browsing not started g_dbus_connection_real_closed: Remote peer vanished with error: Error receiving message: Connection reset by peer (g-io-error-quark, 0). Exiting. Erreur de segmentation (core dumped) A GDB session gives me (see attachment).
Created attachment 279540 [details] Sample SID file
This could also be caused by other parts of the rhythmbox code... it's crashing here because of memory corruption, which could come from everywhere. Can you get a valgrind log of the crash with --track-origins=yes ?
I can reproduce the crash in RB. When running RB under valgrind it hangs after some minutes. I have a hunch that sidedec might corrupt the memory. When running gst-play-1.0 Star_Trekkin.sid under vagrind I get a few conditions depends on uninitialized value plus this: ==838== 16,384 bytes in 1 blocks are definitely lost in loss record 5,806 of 5,846 ==838== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==838== by 0x585D610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==838== by 0x5867445: g_quark_from_static_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0) ==838== by 0x55C94AB: gobject_init_ctor (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0) ==838== by 0x4010139: call_init.part.0 (dl-init.c:78) ==838== by 0x4010222: _dl_init (dl-init.c:36) ==838== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so) ==838== by 0x1: ??? ==838== by 0xFFEFFFC42: ??? ==838== by 0xFFEFFFC4F: ??? The end looks suspicious.
Don't know what to do about this, sorry. Does look like memory corruption, but there are enough other non-GStreamer warnings that look dubious that it's not clear this is something in GStreamer, especially since it's not reproducable in gst-launch. Closing for now since there's not much we can do without more info.