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 323542 - GStreamer 0.10 hangs at EOS for all songs
GStreamer 0.10 hangs at EOS for all songs
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: High critical
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-08 11:47 UTC by Christian Fredrik Kalager Schaller
Modified: 2006-03-03 16:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Attachments
check that GStreamer-for-GLib-2.8 isn't running against GLib-2.6 (812 bytes, patch)
2006-02-11 23:57 UTC, Jan Schmidt 		none Details | Review

Description Christian Fredrik Kalager Schaller 2005-12-08 11:47:13 UTC 
Steps to reproduce:
This is on my system running glib 2.8 while core is compiled against glib 2.6

1.  gst-launch-0.10 playbin uri=file:///home/cschalle/temp/Dirrty_OGG128.ogg
2. Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: audioclock0
Got EOS from element "playbin0".
Execution ended after 19342556000 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...

(gst-launch-0.10:6475): GStreamer-CRITICAL **: gst_object_unref: assertion
`GST_IS_OBJECT (object)' failed


Stack trace:
Breakpoint 2, 0x001a69f2 in g_log () from /usr/lib/libglib-2.0.so.0
(gdb) bt

+ Trace 64488

  • #0 g_log
    from /usr/lib/libglib-2.0.so.0
  • #1 g_return_if_fail_warning
    from /usr/lib/libglib-2.0.so.0
  • #2 gst_object_unref
    at gstobject.c line 392
  • #3 gst_bin_dispose
    at gstbin.c line 379
  • #4 gst_decode_bin_dispose
    at gstdecodebin.c line 352
  • #5 g_object_unref
    from /usr/lib/libgobject-2.0.so.0
  • #6 gst_object_unref
    at gstobject.c line 402
  • #7 unlinked
    at gstdecodebin.c line 992
  • #8 g_cclosure_marshal_VOID__OBJECT
    from /usr/lib/libgobject-2.0.so.0
  • #9 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #10 g_signal_stop_emission
    from /usr/lib/libgobject-2.0.so.0
  • #11 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #12 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #13 gst_pad_unlink
    at gstpad.c line 1440
  • #14 unlink_pads
    at gstbin.c line 666
  • #15 foreach_fold_func
    at gstiterator.c line 528
  • #16 gst_iterator_fold
  • #17 gst_iterator_foreach
    at gstiterator.c line 554
  • #18 gst_bin_remove_func
    at gstbin.c line 854
  • #19 gst_bin_remove
    at gstbin.c line 970
  • #20 gst_bin_dispose
    at gstbin.c line 384
  • #21 gst_decode_bin_dispose
    at gstdecodebin.c line 352
  • #22 g_object_unref
    from /usr/lib/libgobject-2.0.so.0
  • #23 gst_object_unref
    at gstobject.c line 402
  • #24 gst_bin_remove_func
    at gstbin.c line 913
  • #25 gst_bin_remove
    at gstbin.c line 970
  • #26 gst_bin_dispose
    at gstbin.c line 384
  • #27 gst_pipeline_dispose
    at gstpipeline.c line 180
  • #28 gst_play_base_bin_dispose
    at gstplaybasebin.c line 216
  • #29 gst_play_bin_dispose
    at gstplaybin.c line 260
  • #30 g_object_unref
    from /usr/lib/libgobject-2.0.so.0
  • #31 gst_object_unref
    at gstobject.c line 402
  • #32 main
    at gst-launch.c line 687
  • #1 g_return_if_fail_warning
    from /usr/lib/libglib-2.0.so.0
  • #2 gst_object_unref
    at gstobject.c line 392
  • #3 gst_bin_dispose
    at gstbin.c line 379 


Other information:
Comment 1 Christian Fredrik Kalager Schaller 2005-12-08 13:04:15 UTC 
Recompiled core against, 2.8 and the issue goes away. So this is a continuation
of the problem of using glib 2.6 compiled packages against glib 2.8
Comment 2 Jan Schmidt 2006-01-23 15:05:35 UTC 
Is this fixed? Does anyone still have a way to test it?
Comment 3 Christian Fredrik Kalager Schaller 2006-01-23 15:20:11 UTC 
One of the beta-testers got it too. I don't think we can fix it. So I guess we should close it as a 'wontfix' or a 'notabug' depending on how we define the issue.
Comment 4 Tim-Philipp Müller 2006-01-23 15:45:08 UTC 
FWIW, the assertion warning is fixed in core CVS, but I doubt that's responsible for the hang.
Comment 5 Jan Schmidt 2006-01-30 14:21:40 UTC 
Is it worth adding a runtime check to gst_init to confirm the version of glib we're built against and fail the initilisation when running gst-built-for-glib-2.6 against glib 2.8, or vice versa?
Comment 6 Jan Schmidt 2006-02-11 23:57:07 UTC 
Created attachment 59159 [details] [review]
check that GStreamer-for-GLib-2.8 isn't running against GLib-2.6

Here's a patch that will produce a g_warning when GStreamer is initialised against  GLib 2.6 if it was built without the refcount hack
Comment 7 Jan Schmidt 2006-02-14 09:18:07 UTC 
Christian, I realised that you said "So this is a continuation
of the problem of using glib 2.6 compiled packages against glib 2.8", which isn't supposed to cause trouble. Did you actually mean 'GStreamer compiled for GLib 2.8 but running against GLib 2.6'?

If so, we should apply my patch and close this bug.
Comment 8 Jan Schmidt 2006-03-03 16:59:11 UTC 
Uraeus confirmed on IRC that he definitely meant a gstreamer built against glib 2.6 but actually running on 2.8. Apparently both arrangements can cause problems, so I've updated the patch to check for both scenarios and output a g_warning when GStreamer is initialised.

        * gst/gst.c:
        Add a check and output a g_warning when GStreamer is built against GLib 2.6 but running against 2.8 or higher, and vice versa. (Closes: #323542)