GNOME Bugzilla – Bug 353976
asssertion about element sanity in gst_registry_xml_write_cache during gst_init
Last modified: 2006-09-03 11:08:13 UTC
I'm on Ubuntu Edgy Eft/HEAD with gstreamer 0.10.9. A stacktrace similar to the attached one is received when running any gst 0.10 application. It seems to be issued by a bogus module, but I also wonder why the init code asserts that a module/element factory isn't broken instead of just bailing (i.e. a g_message could be enough). Memory status: size: 38359040 vsize: 0 resident: 38359040 share: 0 rss: 10706944 rss_rlim: 0 CPU usage: start_time: 1157208841 rtime: 0 utime: 52 stime: 0 cutime:44 cstime: 0 timeout: 8 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gnome-settings-daemon' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1225673040 (LWP 28153)] (no debugging symbols found) 0xffffe410 in __kernel_vsyscall ()
+ Trace 71415
Thread 1 (Thread -1225673040 (LWP 28153))
Of course, I've tried to use gdb to track down which module/element factory is faulty. I had to rebuild the gstreamer packages from source because somehow the tracepoints didn't trigger, and a simple printf debugging session yielded that my gnomevfssink doesn't provide any uri_protocols. More on that in another bug report.
unique, confirming good trace.
Thanks, fixed: 2006-09-03 Tim-Philipp Müller <tim at centricular dot net> * gst/gstregistryxml.c: (gst_registry_xml_save_feature): Print a warning rather than g_assert() if a plugin feature is a URI handler but returns no protocols (#353976).