[Bug 796692] bufferlist: gst_buffer_list_get() can give a writable reference to multiple threads at the same time

[GStreamer (GNOME Bugzilla)]

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

--- Comment #20 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #19)
> Yeah, I don't think MiniObject already have any mechanism to implement this
> solution. Do you think it's worth it, or does a solution where
> buffer_list_get users needs to be aware of writability works fine enough ?

That's not enough unfortunately as explained above (and it already is part of
the gst_buffer_list_get_buffer() API that the return value is not writable,
that's why get_writable_buffer() exists). The problem is that even if *you*
don't do any operation on the buffer that requires writability, some other code
outside your control might. Like in my case read-mapping the buffer, which
merges and replaces all memories inside the buffer if the buffer happens to be
writable.

A possible solution is to never replace the memories of course, but that does
not prevent other accidental modifications like this elsewhere.

I think the only possible solutions are
1) Deprecating get_buffer() and add a new dup_buffer() that returns a new
reference
2) Find a backwards compatible way of coupling the "parent" (buffer list)
refcount with the writability of the buffer


And I just noticed that the same problem does not affect only buffer lists but
also GstSample. Exactly same problem really. Aaaand GstBuffer with the
contained GstMemories, see following testcase (buffer could be in two places at
once, memory refcount==1, both places could modify the memory via e.g.
gst_memory_resize() or both map the memory writable and modify them together).


I think we need a general solution for extending miniobject writability so that
miniobjects owned by another one are only writable if the parent refcount is 1
and their own is too. I'll experiment with that.

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