After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 353976 - asssertion about element sanity in gst_registry_xml_write_cache during gst_init
asssertion about element sanity in gst_registry_xml_write_cache during gst_init
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other Linux
: Normal critical
: 0.10.10
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-02 15:09 UTC by Christian Neumair
Modified: 2006-09-03 11:08 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Christian Neumair 2006-09-02 15:09:05 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 ()

Thread 1 (Thread -1225673040 (LWP 28153))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 libgnomeui_segv_handle
    at gnome-ui-init.c line 871
  • #3 <signal handler called>
  • #4 __kernel_vsyscall
  • #5 *__GI_raise
    from /lib/tls/i686/cmov/libc.so.6
  • #6 *__GI_abort
    from /lib/tls/i686/cmov/libc.so.6
  • #7 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #8 g_log
    from /usr/lib/libglib-2.0.so.0
  • #9 g_assert_warning
    from /usr/lib/libglib-2.0.so.0
  • #10 gst_registry_xml_write_cache
    at gstregistryxml.c line 721
  • #11 scan_and_update_registry
    at gst.c line 636
  • #12 init_post
    at gst.c line 678
  • #13 g_option_context_parse
    from /usr/lib/libglib-2.0.so.0
  • #14 gst_init_check
    at gst.c line 355
  • #15 gst_init
    at gst.c line 389
  • #16 acme_volume_gstreamer_get_type
  • #17 g_type_class_ref
    from /usr/lib/libgobject-2.0.so.0
  • #18 g_object_newv
    from /usr/lib/libgobject-2.0.so.0
  • #19 g_object_new_valist
    from /usr/lib/libgobject-2.0.so.0
  • #20 g_object_new
    from /usr/lib/libgobject-2.0.so.0
  • #21 acme_volume_new
  • #22 gnome_settings_multimedia_keys_load
  • #23 gnome_settings_daemon_new
  • #24 main
  • #0 __kernel_vsyscall


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.
Comment 1 Christian Kirbach 2006-09-03 10:36:07 UTC
unique, confirming good trace.
Comment 2 Tim-Philipp Müller 2006-09-03 11:08:13 UTC
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).