GNOME Bugzilla – Bug 768179
Hang while changing to pause mode in id3demux
Last modified: 2018-11-03 12:35:21 UTC
Created attachment 330570 [details] ID3 hang on changing state to pause Hang is seen while changing state to pause on multiple playbacks of few id3v2 tag files. On analysing this issue I found that while changing typefind from push to pull mode, it performs a gst_pad_pause_task where it is trying to take STREAM_LOCK and hangs there. Logs attached. This issue cannot be seen if id3demux is in push mode.
Can you try with 1.8.2, and also get a backtrace of all threads when it hangs? Alternatively please provide a small, runnable testcase that reproduces your problem. What is the pipeline that is used, which non-standard (e.g. hardware specific) elements are used and do you still have the problem without them?
Below is the pipeline that I am using : gst-launch-1.0 filesrc location=/home/jyoti/Documents/mp3/8kbps_32khz_2ch.mp3 ! typefind ! id3demux ! mpegaudioparse ! avdec_mp3 ! audioconvert ! capsfilter caps="audio/x-raw,channels=2" ! volume ! audioresample ! capsfilter caps="audio/x-raw,rate=48000" ! alsasink Issue is seen only on recursively creating and destroying the pipeline.Below are the steps that we take to create the pipeline: 1.Create elements source, typefind, faksink, put them to bin and set pipeline state to PAUSE. 2.In callback function of typefind, depending on the type we create the demuxers. 3 Based on the caps notification from the demuxer, we create rest of the elements and sync there state and set pipeline to play. 4. Once pipeline is set to play,to destroy we get the state of pipeline if not NULL, we set state to NULL and unref the pipeline. The above steps are repeated for about 200-500 times and we get no caps notification from id3demux because of the hang mentioned. Will update on the other queries and sample application as soon as possible.
Created attachment 330657 [details] Id3 hang issue Attached the test app file to verify this issue. Usage: ./a.out <filelocation> Also I tried on PC with the same test app but can not reproduce this issue though I could reproduce this on freescale board(gstreamer version 1.4.1)
Is there any update on this bug? It looks like typefind src pad mode changing from push to pull is hanging. Not able to complete activation of pull mode. Can you please check and update the same? We are not able to change status. Please update status. If still more information needed let us know.
Can you check on the Freescale board if you can reproduce it with 1.8.2 or GIT master? There were some related changes to the typefind element during 1.8. If this is not reproducible by anybody, it's going to be a bit tricky to fix.
I got it to happen once:
+ Trace 236501
Thread 2 (Thread 0x7f8bcd21d700 (LWP 6448))
Better stack trace (I was using a non current branch of master for the one above):
+ Trace 236503
I wonder if the gst_element_sync_state_with_parent ought not be done in a idle pad block. As in, I'm not sure whether this is a real bug in gst, or just a "don't do that, then". slomo ? :)
You should never do state changes from the corresponding streaming thread, which an IDLE probe might be. You can only change states of downstream elements at that point.
So that leaves an g_idle routine I guess. The type found callback is squarely in the streaming thread anyway. So I guess this can be closed, unless the reported thinks there's something else going on.
Can't use g_idle_*() since we can't assume that someone is running a glib main loop / iterating a main context (unless your element is doing it for its own stuff). Helper thread/task should work.
As per my understanding sync_state_with_parent is causing the issue. Can gst_element_set_state be used in its place to avoid this issue?As I want my elements to be in paused state(state of BIN)after adding to pipeline.
It has the same problems, the problem is calling gst_element_set_state() from a streaming thread on an element that is currently inside this very streaming thread.
So what can be an alternative to this? Changing elements state from non streaming thread? and all the calls to set_state should be called from separate thread. Also as I can see in playbin code elements state is changed within the same thread after locking the element and then unlocking it but I dont see this issue using playbin.
Sebastian, my reading of the stack trace in comment #7 is that we're in the typefind type-found callback (streaming thread), and there we have added a new id3demux element downstream which we're setting to the state of the pipeline via _sync_state(). This should surely be alright? We must set the state in the callback here otherwise it will be racy and typefind might push a buffer on a not-yet-active element. Maybe the problem is _sync_state() and it should just be _set_state() ? I also wouldn't be surprised if there's a bug in typefind or tagdemux, both have fairly complicated logic to switch pad modes and such on the fly IIRC.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/178.