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 134663 - failed assertion at end of movie in totem
failed assertion at end of movie in totem
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: High critical
: 0.8.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-02-17 18:51 UTC by Jon Trowbridge
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jon Trowbridge 2004-02-17 18:51:46 UTC
I was playing matrix.avi, and right at the end I got a whole bunch of

(totem:6389): GStreamer-CRITICAL **: file gstdata.c: line 236
(gst_data_unref): assertion `GST_DATA_REFCOUNT_VALUE (data) > 0' failed
 
(totem:6390): GStreamer-CRITICAL **: file gstdata.c: line 188
(gst_data_ref): assertion `GST_DATA_REFCOUNT_VALUE(data) > 0' failed

followed by a failed assertion:

GStreamer-ERROR **: file gstpad.c: line 2687 (gst_real_pad_dispose):
assertion failed: (GST_PAD_PEER (pad) == NULL)
aborting...
 
Program received signal SIGTRAP, Trace/breakpoint trap.

Thread 32771 (LWP 6390)

  • #0 g_logv
  • #1 g_log
  • #2 gst_real_pad_dispose
    at gstpad.c line 2687
  • #3 g_object_last_unref
    at gobject.c line 557
  • #4 g_object_unref
    at gobject.c line 1590
  • #5 gst_object_unref
    at gstobject.c line 242
  • #6 _gst_event_free
    at gstevent.c line 91
  • #7 gst_data_unref
    at gstdata.c line 243
  • #8 gst_pad_event_default_dispatch
    at gstpad.c line 3479
  • #9 gst_pad_event_default
    at gstpad.c line 3505
  • #10 gst_pad_send_event
    at gstpad.c line 3604
  • #11 gst_opt_scheduler_chain_wrapper
    at gstoptimalscheduler.c line 1155
  • #12 gst_pad_push
    at gstpad.c line 2902
  • #13 gst_switch_loop
    at gstswitch.c line 209
  • #14 loop_group_schedule_function
    at gstoptimalscheduler.c line 997
  • #15 schedule_group
    at gstoptimalscheduler.c line 842
  • #16 gst_opt_scheduler_schedule_run_queue
    at gstoptimalscheduler.c line 881
  • #17 schedule_chain
    at gstoptimalscheduler.c line 925
  • #18 gst_opt_scheduler_iterate
    at gstoptimalscheduler.c line 2068
  • #19 gst_scheduler_iterate
    at gstscheduler.c line 705
  • #20 gst_bin_iterate_func
    at gstbin.c line 1081
  • #21 gst_marshal_BOOLEAN__VOID
    at gstmarshal.c line 394
  • #22 g_type_class_meta_marshal
    at gclosure.c line 514
  • #23 g_closure_invoke
    at gclosure.c line 437
  • #24 signal_emit_unlocked_R
    at gsignal.c line 2474
  • #25 g_signal_emit_valist
    at gsignal.c line 2205
  • #26 g_signal_emit
    at gsignal.c line 2239
  • #27 gst_bin_iterate
    at gstbin.c line 1120
  • #28 gst_thread_main_loop
    at gstthread.c line 552
  • #29 g_thread_create_proxy
    at gthread.c line 601
  • #30 pthread_start_thread
    from /lib/i686/libpthread.so.0
  • #31 pthread_start_thread_event
    from /lib/i686/libpthread.so.0
  • #32 clone
    from /lib/i686/libc.so.6

Comment 1 Elijah Newren 2004-02-18 01:14:09 UTC
Thanks for the bug report.  This appears to be a unique stack trace,
according to the simple-dup-finder.   I'm going to set some fields
appropriately.
Comment 2 Thomas Vander Stichele 2004-07-09 08:22:25 UTC
I fixed a few of these in CVS, so I'll close this bug.  Reopen if still valid,
with a new backtrace.