https://bugzilla.gnome.org/show_bug.cgi?id=769515
Bug ID: 769515
Summary: oggdemux: race with validate tests
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-base
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: gdesmott at gnome.org
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Some validate tests such as
validate.http.playback.fast_forward.vorbis_theora_1_ogg are racy and sometimes
failing (easier to reproduce with no/few logs enabled).
Here is what happens most of the time (test passing):
- gst_ogg_demux_activate_chain: first chain is activated
- GST_EVENT_SEGMENT is received on sinkpad and gst_ogg_demux_reset_streams()
reset the chain
- gst_ogg_demux_activate_chain is called again and the first chain is
re-activated
- souphttpsrc is done reading the file and send EOS
- validate sends a seek event which is handled just fine by oggdemux; all good.
And here is what's happening when the test is failing. The first 2 steps are
the same:
- gst_ogg_demux_activate_chain: first chain is activated
- GST_EVENT_SEGMENT is received on sinkpad and gst_ogg_demux_reset_streams()
reset the chain
But then we reach:
- souphttpsrc is done reading the file and send EOS
This happens BEFORE oggdemux had a chance to re-activate the first chain, so
this code path is triggered when handling the EOS from souphttpsrc:
if (ogg->current_chain == NULL) {
GST_WARNING_OBJECT (ogg,
"EOS while trying to retrieve chain, seeking disabled");
ogg->push_disable_seeking = TRUE;
Then when validate sends the seek event it's not handled as
ogg->push_disable_seeking is TRUE.
Should gst_ogg_demux_activate_chain() set push_disable_seeking to FALSE?
That should greatly reduce the risk of hitting the race but it could (I think?)
still happen if the seek event is send before the chain has been re-activated.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.