Description of problem: Some apps, like pidgin, fail during startup as libgstreamer loads its plugins. Version-Release number of selected component (if applicable): gstreamer-plugins-bad-free-0.10.18.x86_64 pidgin-2.6.6.x86_64 gstreamer-0.10.28.x86_64 How reproducible: 100% Steps to Reproduce: 1.Try to start pidgin (or other app that uses those components) 2. 3. Actual results: anxiety:~$ pidgin ERROR: Caught a segmentation fault while loading plugin file: /usr/lib64/gstreamer-0.10/libgstlv2.so Please either: - remove it and restart. - run with --gst-disable-segtrap and debug. anxiety(255):~$ Expected results: Apps work Additional info:
Please get a backtrace from the crash.
(gdb) run Starting program: /usr/bin/pidgin [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:106 106 movlpd (%rdi), %xmm1 (gdb) bt #0 __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:106 #1 0x000000306725fa39 in IA__g_str_equal (v1=<value optimized out>, v2=<value optimized out>) at gstring.c:116 #2 0x000000306722d0f7 in g_hash_table_lookup_node (hash_table=0x713450 = {...}, key=0x7fffcc654e00) at ghash.c:327 #3 IA__g_hash_table_lookup (hash_table=0x713450 = {...}, key=0x7fffcc654e00) at ghash.c:898 #4 0x0000003067226dbb in g_quark_from_string_internal (string=0x7fffcc654e00 "GstSignalProcessor") at gdataset.c:1015 #5 IA__g_intern_static_string (string=0x7fffcc654e00 "GstSignalProcessor") at gdataset.c:1175 #6 0x00007fffcc652854 in gst_signal_processor_get_type () from /usr/lib64/libgstsignalprocessor-0.10.so.0 #7 0x00007fffcc859640 in g_strcanon () at gstrfuncs.c:2180 #8 0x00000030736647c6 in gst_plugin_register_func (plugin=0xa12180 [GstPlugin], desc=0x7fffcca5c8e0, user_data=0x0) at gstplugin.c:422 #9 0x0000003073665d94 in gst_plugin_load_file (filename=0xa0eae0 "/usr/lib64/gstreamer-0.10/libgstlv2.so", error=<value optimized out>) at gstplugin.c:643 #10 0x000000307366fc2c in gst_registry_scan_plugin_file (context=0x7fffffffbf80, filename=0xa0eae0 "/usr/lib64/gstreamer-0.10/libgstlv2.so", file_size=24848, file_mtime=1268123890) at gstregistry.c:1045 #11 0x0000003073671431 in gst_registry_scan_path_level (context=0x7fffffffbf80, path=0x30736b13d7 "/usr/lib64/gstreamer-0.10", level=<value optimized out>) at gstregistry.c:1170 #12 0x00000030736715e9 in gst_registry_scan_path_internal (context=0x7fffffffbf80, path=0x30736b13d7 "/usr/lib64/gstreamer-0.10") at gstregistry.c:1197 #13 0x0000003073672e35 in scan_and_update_registry () at gstregistry.c:1464 #14 ensure_current_registry () at gstregistry.c:1564 #15 gst_update_registry () at gstregistry.c:1646 #16 0x00000030736297d5 in init_post (context=<value optimized out>, group=<value optimized out>, data=<value optimized out>, error=<value optimized out>) at gst.c:783 #17 0x000000306724aa29 in IA__g_option_context_parse (context=0x932920, argc=<value optimized out>, argv=<value optimized out>, error=<value optimized out>) at goption.c:1947 #18 0x0000003073628f15 in gst_init_check (argc=0x0, argv=0x0, err=0x7fffffffc170) at gst.c:446 #19 0x00000000004b47c5 in ?? () #20 0x000000000048ce64 in ?? () #21 0x000000306da66e29 in purple_core_init () from /usr/lib64/libpurple.so.0 #22 0x000000000048d592 in main () (gdb)
Looks like "GstSignalProcessor" might have been declared in 2 plugins, or in one of the helper libraries. What's the output of: rpm -qa "gst*"
gstreamer-plugins-bad-free-0.10.18.x86_64 gstreamer-plugins-base-0.10.28.x86_64 gstreamer-tools-0.10.28.x86_64 gstreamer-python-0.10.16.x86_64 gstreamer-debuginfo-0.10.28.x86_64 gstreamer-0.10.28.x86_64 gstreamer-plugins-good-0.10.21.x86_64 gstreamer-plugins-base-debuginfo-0.10.28.x86_64
I think I know what the problem is, and have already committed a potential fix to upstream (http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=8fe63000de31bb2bcf346d59230dea06117997cd). Before I spin new releases could you do these things and report if the SEGV goes away: 1) rm ~/.gstreamer-0.10/*.bin to ensure the registry gets rebuilt 2) Install some random LADSPA plugin package, so that at least one LADSPA plugin exists 3) restart pidgin This should work around the problem.
That seems to have fixed it.
We had a very similar issue in F-12 some time ago. Could it be that this has returned to F-12 with the latest round of updates there ? If so we need to hurry with a fix, as this causes nautilus to not start.
You cannot use g_quark_from_static_string from an unloadable module, since it assumes that the memory will remain valid for the lifetime of the process. Just use g_quark_from_string in that case. Forcing modules to remain resident is a brute-force fix for this problem.
No, it is not. In general, GStreamer assumes that plugins are unloadable. Every type is registered statically for example. The reason for this is that the GType system is mostly unsuited for unloading and most libraries we link to are not capable of unloading at all. And then, there's no real gain in unloading, as the only real benefit we get from unloading would be more address space in the application. And I'm not aware of any GStreamer app having problems with running out of address space. So making the module resident is (as the code comment says) just to make sure that we keep our promise to never unload a module. We didn't close modules at all anyway. The only exception to that case was the current problem. GStreamer treated the return value of the plugin init function as "Should we immediately unload the plugin?" while the plugin implementors think of the return value as "Did we fail to properly initialize?" and the patch just ensures the core agrees with the plugins. All of this is not a big problem anyway, because it's a code path only run by the plugin scanner (or pidgin, which intentionally breaks it because it thinks crashing is cool). Normal applications will know that the plugin shouldn't be loaded and ignore it. That said, in this particular case the g_quark_from_static_string() is only one issue. The other is the g_type_class_ref() of GstSignalProcessor. Unreffing it later is not enough, we'd need to either ensure the library providing it stays in memory or make the library unloadable.
gstreamer-0.10.28-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gstreamer-0.10.28-2.fc13
gstreamer-0.10.28-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gstreamer-0.10.28-2.fc12
gstreamer-0.10.28-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gstreamer'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/gstreamer-0.10.28-2.fc13
gstreamer-0.10.28-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gstreamer'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/gstreamer-0.10.28-2.fc12
gstreamer-0.10.28-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
gstreamer-0.10.28-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 575958 has been marked as a duplicate of this bug. ***