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 769515 - oggdemux: race with validate tests
oggdemux: race with validate tests
Status: RESOLVED DUPLICATE of bug 767689
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-04 14:18 UTC by Guillaume Desmottes
Modified: 2016-08-05 11:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Guillaume Desmottes 2016-08-04 14:18:50 UTC
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.
Comment 1 Vincent Penquerc'h 2016-08-04 14:28:34 UTC
Does the patch in https://bugzilla.gnome.org/show_bug.cgi?id=767689 help ?
Comment 2 Guillaume Desmottes 2016-08-04 14:46:10 UTC
(In reply to Vincent Penquerc'h from comment #1)
> Does the patch in https://bugzilla.gnome.org/show_bug.cgi?id=767689 help ?

I got the test passing in loop during 15 minutes here while I was usually hitting the race after just a few iterations without your patch. So yeah, that definitely helps.
Comment 3 Edward Hervey 2016-08-05 05:52:40 UTC
Shall we close this now that the other commit is in ? Or wait for a few ci.gst runs before ?
Comment 4 Guillaume Desmottes 2016-08-05 09:47:11 UTC
The remaining failing test (validate.http.playback.seek_backward.vorbis_theora_1_ogg) seems to be another bug so let's close this one and I'll open a new one for it.

*** This bug has been marked as a duplicate of bug 767689 ***
Comment 5 Guillaume Desmottes 2016-08-05 11:02:19 UTC
(In reply to Guillaume Desmottes from comment #4)
> The remaining failing test
> (validate.http.playback.seek_backward.vorbis_theora_1_ogg) seems to be
> another bug so let's close this one and I'll open a new one for it.

For the record I opened bug #769545