GNOME Bugzilla – Bug 347452
Seeking hangs after so many seeks
Last modified: 2006-07-28 14:11:06 UTC
Please describe the problem: In Jokosher you can click on the timeline ruler after pressing play and the pipeline seeks to that point. After a certain amount of seeks (not a reproducable number), Jokosher hangs. This only seems to happen with more than one instrument, which suggests it is an adder related bug. Attached is a log file. Look out for the Python debug messages - I added a message to indicate when we seek. I also included colour in the debug log. Steps to reproduce: 1. In Jokosher, press play. 2. Keep seeking by clicking different bits of the timeline 3. Actual results: It hangs Jokosher. Expected results: It seeks normally. I.e. Doesn't hang. :P Does this happen every time? After so many clicks, yes. Other information: I will buy a pint to a GStreamer developer who fixes this before the next release and gets it included. This way we can run Jokosher completely with the next release due over the next few days.
Created attachment 68887 [details] Debug log. This debug log is for a session where I have two instruments with an ogg file on each and I keep seeking until it hangs.
I did a bit of digging on this last night. I saw 2 separate hangs, attaching backtraces for both. The first one seems to be: A deadlock while sending the seek to sink1 while sink0 is chained through adder to the sink. The 2nd: Sending the seek through sink1 blocks because the stream on sink1 is still blocked at Adder's collectpads as if it never received a flush-start to wake it up.
Created attachment 68910 [details] backtrace for scenario 1
Created attachment 68911 [details] backtrace for scenario 2
Created attachment 68912 [details] last 10MB of a debug log for 'scenario 2'
Lots of fixes here.. sigh... Can't make it deadlock anymore with ./seek 15 "audiotestsrc freq=330 ! adder name=add audiotestsrc freq=550 ! add. add. ! alsasink" in scrubbing mode (which used to lock up after a few seconds of seeking madness before this patch with similar stacktraces as the ones in the bugreport) * libs/gst/base/gstcollectpads.c: (gst_collect_pads_set_flushing_unlocked), (gst_collect_pads_pop), (gst_collect_pads_clear), (gst_collect_pads_flush), (gst_collect_pads_event), (gst_collect_pads_chain): When flushing a pad, also clear the queued buffer so that we don't accidentally use it when we shouldn't. Fix leaks by inreffing incomming buffer. Flush out queued buffers in case of errors. Fixes #347452.