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 166674 - deadlock detected using opt and playbin
deadlock detected using opt and playbin
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-02-08 14:41 UTC by Jan Schmidt
Modified: 2005-06-09 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Schmidt 2005-02-08 14:41:39 UTC
Here's a backtrace captured when using playbin to play a DVD with DTS. This
seems to be caused by dtsdec currently being loopbased.

(gdb) cont
Continuing.

** (totem:9944): WARNING **: deadlock detected, disabling group 0x848f920
ERROR (0x83f0938 - 307742:40:30.541820000)       scheduler( 9944)
gstoptimalscheduler.c(2797):gst_opt_scheduler_iterate:<GstOptScheduler@0x83f0868>
in error state
[New Thread -1253733456 (LWP 10730)]
[New Thread -1255957584 (LWP 10731)]

Breakpoint 2, 0xb75f8e7e in g_log () from /usr/lib/libglib-2.0.so.0
(gdb) cont
Continuing.

** (totem:9944): WARNING **: deadlock detected, disabling group 0x848f920
ERROR (0x83f0938 - 307742:40:44.578405000)       scheduler( 9944)
gstoptimalscheduler.c(2797):gst_opt_scheduler_iterate:<GstOptScheduler@0x83f0868>
in error state

Thread 3 (Thread -1236538448 (LWP 9973))

  • #0 g_log
    from /usr/lib/libglib-2.0.so.0
  • #1 gst_opt_scheduler_get_wrapper
    at gstoptimalscheduler.c line 1588
  • #2 gst_pad_pull
    at gstpad.c line 3347
  • #3 gst_bytestream_get_next_buf
    at bytestream.c line 156
  • #4 gst_bytestream_fill_bytes
    at bytestream.c line 230
  • #5 gst_bytestream_get_timestamp
    at bytestream.c line 725
  • #6 gst_dtsdec_loop
    at gstdtsdec.c line 410
  • #7 loop_group_schedule_function
    at gstoptimalscheduler.c line 1451
  • #8 schedule_group
    at gstoptimalscheduler.c line 1222
  • #9 gst_opt_scheduler_schedule_run_queue
    at gstoptimalscheduler.c line 1274
  • #10 schedule_chain
    at gstoptimalscheduler.c line 1331
  • #11 gst_opt_scheduler_iterate
    at gstoptimalscheduler.c line 2789
  • #12 gst_scheduler_iterate
    at gstscheduler.c line 744
  • #13 gst_bin_iterate_func
    at gstbin.c line 1246
  • #14 gst_marshal_BOOLEAN__VOID
    at gstmarshal.c line 509
  • #15 g_cclosure_new_swap
    from /usr/lib/libgobject-2.0.so.0
  • #16 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #17 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #18 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #19 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #20 gst_bin_iterate
    at gstbin.c line 1306
  • #21 gst_thread_main_loop
    at gstthread.c line 675
  • #22 g_static_private_free
    from /usr/lib/libglib-2.0.so.0
  • #23 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #24 clone
    from /lib/tls/i686/cmov/libc.so.6

Comment 1 Ronald Bultje 2005-02-08 15:05:35 UTC
Can you provide a sample .vob of a few MB for me to reproduce this?
Comment 2 Ronald Bultje 2005-03-11 21:31:44 UTC
I don't see why this happens. The two groups run independently. This did happen
with a very old core (before
http://cvs.freedesktop.org/gstreamer/gstreamer/gst/schedulers/gstoptimalscheduler.c?r1=1.102&r2=1.103
was committed), but frame #9 claims otherwise.

OK, so logically, we have .. ! dvddemux ! dtsdec ! .. as a pipeline, where
dtsdec is the start of a new group. This group is scheduled in frame 8, when
calling schedule_group (group=0x848f920). It calls pull(), which gets data from
the previous group through its output srcpad (on dvddemux). However, this, for
some reason, thinks that dvddemux belongs to the group of dtsdec, given the
warning ** (totem:9944): WARNING **: deadlock detected, disabling group
0x848f920 (note that the pointer is the same!). That implies a bug in group
setup, or a bug in dtsdec when it pulls from the pad. Dtsdec at that point (it's
been rewritten since; good job Jan!) seems ok, so group setup must be bad. Wim,
any idea why it thinks that dvddemux' srcpad-parent (i.e. dvddemux) belongs to
the same group as dtsdec?
Comment 3 Ronald Bultje 2005-06-09 14:26:00 UTC
This is no longer relevant since dtsdec was rewritten. Will reopen if another
element triggers it.