[Bug 738152] New: v4l2bufferpool: leak with output device

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Oct 8 06:33:36 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=738152
  GStreamer | gst-plugins-good | git

           Summary: v4l2bufferpool: leak with output device
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: aurelien.zanelli at parrot.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Using following pipeline, I notice that v4l2 elements leaks v4l2bufferpool,
v4l2allocator, v4l2 buffers and v4l2sink.

GST_TRACE=all gst-launch-1.0 videotestsrc num-buffers=3 ! v4l2sink
enable-last-sample=false

These leaks seems due to the fact that some buffers are queued into the drivers
when we stop the pipeline. Since these buffers are out of the bufferpool, the
bufferpool doesn't stop when calling gst_buffer_set_active(..., FALSE) because
there is outstanding buffers. In this case,bufferpool will be stopped when all
buffers will return to the pool.

But in this case they won't since they are stuck into the driver. For
information, in regular playing, buffers are released when they are dequeued
from drivers in pool_process_buffer.

So as these buffers will never be unref, the v4l2bufferpool won't stop. Since
v4l2_buffer_pool_stop() won'þ be called, v4l2 leaks and doesn't call streamoff.

I think it's a major issue since we don't free drivers resources (v4l2 buffer)
and we don't call STREAMOFF.

-- 
Configure bugmail: https://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.


More information about the gstreamer-bugs mailing list