[Bug 792575] New: Switching a lot between pause/playing state, endless hanging of GST_STATE_WAIT inside gst_element_get_state_func

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Jan 16 13:48:11 UTC 2018


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

            Bug ID: 792575
           Summary: Switching a lot between pause/playing state, endless
                    hanging of GST_STATE_WAIT inside
                    gst_element_get_state_func
    Classification: Platform
           Product: GStreamer
           Version: 1.12.4
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: meinemailingliste2 at online.de
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 366884
  --> https://bugzilla.gnome.org/attachment.cgi?id=366884&action=edit
Logfile of error, error completely at the end of logfile

I am switching a small playback pipeline (on i.MX6)

splitmuxsrc->h264parse->v4l2h264dec->v4l2sink

again and again from pause to playing and back to pause by keypresses.

Just before setting the pipeline to state PLAYING,
I query the current state (just for debugging) via

GstStateChangeReturn rv;
GstState state;
rv = gst_element_get_state(m_pPipeline, &state, NULL, GST_CLOCK_TIME_NONE);

When pressing the key fast enough or just with the right speed,
the program is hanging. I located the hanging in above code,
especially in function gst_element_get_state.
Adding further debug info it seems it is hanging here
just between debug output "MIDDLE 2a" and "MIDDLE 2b":

/* MT safe */
static GstStateChangeReturn
gst_element_get_state_func (GstElement * element,
    GstState * state, GstState * pending, GstClockTime timeout)
{
  GstStateChangeReturn ret = GST_STATE_CHANGE_FAILURE;
  GstState old_pending;

  fprintf(stderr, "MMMM I am in gst_element_get_state_func START\n");

  GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element, "getting state, timeout %"
      GST_TIME_FORMAT, GST_TIME_ARGS (timeout));

  GST_OBJECT_LOCK (element);
  ret = GST_STATE_RETURN (element);
  GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element, "RETURN is %s",
      gst_element_state_change_return_get_name (ret));

  fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 1\n");

  /* we got an error, report immediately */
  if (ret == GST_STATE_CHANGE_FAILURE)
    goto done;

  /* we got no_preroll, report immediately */
  if (ret == GST_STATE_CHANGE_NO_PREROLL)
    goto done;

  /* no need to wait async if we are not async */
  if (ret != GST_STATE_CHANGE_ASYNC)
    goto done;

  old_pending = GST_STATE_PENDING (element);
  if (old_pending != GST_STATE_VOID_PENDING) {
    gboolean signaled;
    guint32 cookie;

    fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 2\n");

    /* get cookie to detect state changes during waiting */
    cookie = element->state_cookie;

    GST_CAT_INFO_OBJECT (GST_CAT_STATES, element,
        "waiting for element to commit state");

    /* we have a pending state change, wait for it to complete */
    if (timeout != GST_CLOCK_TIME_NONE) {
      gint64 end_time;
      /* make timeout absolute */
      end_time = g_get_monotonic_time () + (timeout / 1000);
      signaled = GST_STATE_WAIT_UNTIL (element, end_time);
    } else {
      fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 2a\n");
      GST_STATE_WAIT (element);
      fprintf(stderr, "MMMM I am in gst_element_get_state_func MIDDLE 2b\n");
      signaled = TRUE;
    }
...
}

In the beginning of the function gst_element_get_state_func
there is GST_OBJECT_LOCK (element);
Could there be some situation where we lock out the background task
from doing some change of state, but then wait till this background task
is finished?

How to continue analysis? An idea what could go wrong here?

Logfile of gstreamer attached.

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


More information about the gstreamer-bugs mailing list