[Bug 796692] New: buffer: gst_buffer_peek_memory() is inherently unsafe

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 796692
           Summary: buffer: gst_buffer_peek_memory() is inherently unsafe
    Classification: Platform
           Product: GStreamer
           Version: unspecified
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: slomo at coaxion.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 372847
  --> https://bugzilla.gnome.org/attachment.cgi?id=372847&action=edit
testcase

In various places we currently use gst_buffer_peek_memory() on a buffer that is
passed into the element and then do something with the memory, like mapping it,
etc. In general it's unknown in these cases if the buffer is also having
another reference elsewhere.

Now gst_buffer_map() (and other functions) can merge all memories inside the
buffer and unref the old memories. This can happen even if the buffer is not
writable and it's safe because of the mini object locking stuff, supposedly.

However what happens is that other code might have a pointer to those memories
that are unreffed (and destroyed) via gst_buffer_peek_memory(), and then access
invalid memory or otherwise fail in interesting ways.

Attached testcase shows this problem in an easy way.


My proposal would be to deprecate gst_buffer_peek_memory() because it's a
footgun and can't be used correctly unless you first ensure that your buffer is
writable.

And then we can add a new functions possibly that does the same but first
ensures that the buffer is actually writable first.

Currently there are many users of gst_buffer_peek_memory() unfortunately.


For the curious, I found this because gst-rtsp-server crashed: multiudpsink was
using gst_buffer_peek_memory() for sending the data, and another thread was
calling gst_buffer_map() on the same buffer and merging/unreffing the memory
then.

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