[Bug 759503] New: Stopping a stream very soon after starting asserts

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759503

            Bug ID: 759503
           Summary: Stopping a stream very soon after starting asserts
    Classification: Platform
           Product: GStreamer
           Version: 1.6.2
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: davecraig at unbalancedaudio.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When I run the attached example code on my target hardware it asserts when the
millisecond delay hits around 300ms. The original assert was intermittent and
racey, so there's an additional change required to open up the race. In
gstbaseparse.c:

   /* should have caps by now */
   if (!gst_pad_has_current_caps (parse->srcpad))
     goto no_caps;

+  /* Open up race.. */
+  g_usleep (100000);

   if (G_UNLIKELY (!parse->priv->checked_media)) {
     /* have caps; check identity */
     gst_base_parse_check_media (parse);
   }

The resulting assert is identical to the one mentioned in bug 755123 comment
11. The summary of what appears to be happening is...

Inside gst_base_parse_push_frame, it checks to see whether the srcpad has caps
before carrying on. In our crash situation this test passes, but the caps have
gone (because another thread has put the pad into FLUSHING mode) by further
down the function when it calls gst_aac_parse_pre_push_frame. 

Although gst_pad_set_active appears to only set the pad to FLUSHING on return
from gst_pad_activate_mode, pre_activate inside gst_pad_activate_mode has
already set the pad to FLUSHING.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.