[gstreamer-bugs] [Bug 340174] New: locking problem in gstbasesink

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=340174
 GStreamer | gstreamer (core) | Ver: 0.10.x

           Summary: locking problem in gstbasesink
           Product: GStreamer
           Version: 0.10.x
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: philippero at libertysurf.fr
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


I hope this won't be a bold comment again ;).

When changing state from PLAYING to PAUSED basesink tries to lock the
PREROLL_LOCK (line 2476). It does the same thing before calling the ::render
method of the object in gst_base_sink_queue_object (line 1664). So far so good.

But, if the sink is in ::render, blocking to wait for a condition that would
allow it to write (like fdsink blocking on select(), waiting for the file
descriptor to be ready for a write) it might block since
gst_base_sink_change_state calls the ::unlock method of the object AFTER trying
to take the PREROLL_LOCK

One obvious solution (and working though not necessarily the best) would be to
call the ::unlock method before trying to take the preroll_lock in
gst_base_sink_change_state.

Sorry if I'm not clear enough.

NOTE: I noticed that the same problem can happen in gst_base_sink_set_flushing
()


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.