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 158162 - opt deadlock
opt deadlock
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.8.8
Assigned To: Wim Taymans
GStreamer Maintainers
: 156741 162005 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-11-13 12:02 UTC by Ronald Bultje
Modified: 2005-01-29 14:06 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch to reproduce the problem (28.12 KB, patch)
2004-11-13 12:03 UTC, Ronald Bultje 		none Details | Review
possible fix (2.74 KB, patch)
2004-12-03 17:44 UTC, Ronald Bultje 		none Details | Review

Description Ronald Bultje 2004-11-13 12:02:18 UTC 
Attached patch adds an APEv1/2 tag reader. APEv1/2 is used for musepack files,
for example, it's similar in scope to ID3v1/2. The element is loopbased, just
like alsasink and musepackdec, but unlike osssink. Consider the following pipelines:

1: gst-launch filesrc location=$file ! apedemux ! musepackdec ! audioconvert !
alsasink
2: gst-launch filesrc location=$file ! decodebin ! audioconvert ! alsasink
3: gst-launch filesrc location=$file ! decodebin ! audioconvert ! osssink
4: gst-launch filesrc location=$file ! decodebin ! { queue ! audioconvert !
alsasink }

1, 3 and 4 work (also if you s/decodebin/spider/). 2 fails with this warning
(for both decodebin and spider):

** (process:8340): WARNING **: deadlock detected, disabling group 0x9caa420

A backtrace on that warning shows that inside the loopfunc of musepackdec (on
gst_pad_pull), it goes to the loopfunc of alsasink (instead of apedemux):

(gdb) bt

+ Trace 51918

  • #0 _dl_sysinfo_int80
    from /lib/ld-linux.so.2
  • #1 raise
    from /lib/tls/libc.so.6
  • #2 abort
    from /lib/tls/libc.so.6
  • #3 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #4 g_log
    from /usr/lib/libglib-2.0.so.0
  • #5 gst_opt_scheduler_get_wrapper
    at gstoptimalscheduler.c line 1458
  • #6 gst_pad_pull
    at gstpad.c line 3271
  • #7 gst_alsa_sink_loop
    at gstalsasink.c line 378
  • #8 loop_group_schedule_function
    at gstoptimalscheduler.c line 1325
  • #9 schedule_group
    at gstoptimalscheduler.c line 1151
  • #10 gst_opt_scheduler_schedule_run_queue
    at gstoptimalscheduler.c line 1198
  • #11 gst_opt_scheduler_get_wrapper
    at gstoptimalscheduler.c line 1444
  • #12 gst_pad_pull
    at gstpad.c line 3271
  • #13 gst_bytestream_get_next_buf
    at bytestream.c line 156
  • #14 gst_bytestream_fill_bytes
    at bytestream.c line 230
  • #15 gst_bytestream_peek_bytes
  • #16 GstMusepackReader::seek
    at gstmusepackreader.cpp line 127
  • #17 JumpID3v2
    from /usr/lib/libmusepack.so.1
  • #18 StreamInfo::ReadStreamInfo
    from /usr/lib/libmusepack.so.1
  • #19 gst_musepack_stream_init
    at gstmusepackdec.cpp line 360
  • #20 gst_musepackdec_loop
    at gstmusepackdec.cpp line 413
  • #21 loop_group_schedule_function
    at gstoptimalscheduler.c line 1325
  • #22 schedule_group
    at gstoptimalscheduler.c line 1151
  • #23 gst_opt_scheduler_schedule_run_queue
    at gstoptimalscheduler.c line 1198
  • #24 schedule_chain
    at gstoptimalscheduler.c line 1251
  • #25 gst_opt_scheduler_iterate
    at gstoptimalscheduler.c line 2613
  • #26 gst_scheduler_iterate
    at gstscheduler.c line 738
  • #27 gst_bin_iterate_func
    at gstbin.c line 1213
  • #28 gst_marshal_BOOLEAN__VOID 

Sample musepack file with ape tags is in the media directory on our website in
medium/. I'll attach the apedemux patch below.
Comment 1 Ronald Bultje 2004-11-13 12:03:50 UTC 
Created attachment 33728 [details] [review]
Patch to reproduce the problem
Comment 2 Ronald Bultje 2004-12-03 17:44:51 UTC 
Created attachment 34460 [details] [review]
possible fix

Attached patch adds a 'run-only-me' property to the _run_queue() function in
opt. _run_queue() is called from two different functions, either
schedule_chain() and the opt _get_wrapper(). In the last case, you don't
actually want to schedule any other elements but the one in the get-group. In
the first case, you don't care which are scheduled. The reason for this
distinction (I think) is that you can 'queue' chain data, whereas gets need to
be handled as quickly as possible, without recursing into any other groups
(which also causes the above deadlock).

I didn't look too closely, didn't run testsuites (bad me), but the above
pipeline (filesrc location=filewithapetags.mpc ! decodebin ! alsasink) works
for me now.
Comment 3 Ronald Bultje 2004-12-09 13:14:14 UTC 
Applied.
Comment 4 Ronald Bultje 2004-12-22 18:32:17 UTC 
*** Bug 162005 has been marked as a duplicate of this bug. ***
Comment 5 Ronald Bultje 2005-01-29 14:06:30 UTC 
*** Bug 156741 has been marked as a duplicate of this bug. ***