[Bug 796692] sample/bufferlist/buffer: Non-writable container miniobjects allow writable access to their contents, causing memory problems

[GStreamer (GNOME Bugzilla)]

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

--- Comment #25 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #24)
> I didn't want to propose it, but we are pretty stuck. We could steal qdata
> pointer, allocate an array of two.
> 
>   qdata = g_new (GstQData, 2);

Yeah we can basically do anything we want with the qdata pointer and qdata
length integer, they're only internally used.

I was thinking of always allocating something (parent tracking and the actual
qdata storage) into the pointer but that would mean that every miniobject is
now going to be two allocations. Far from ideal but probably the best of all
options at this point.

Note that the pointer is a plain gpointer, we can store a struct there that
directly stores the parents and then the qdata. No need to keep the current
qdata struct there, it's internal. I guess that's the only good news :)

> Use qdata[0].data as out private pointer, and qdata[1].data as our qdata
> storage. Or something along these lines ... not great. From there, we could
> add a new function callback (ref callback)

Similar to what you did in your bufferlist patch so that bufferlist can
override that reffing also refs each buffer inside it? That's quite heavy and I
would prefer to not do that :)

> or implement your parenting design, which seems more lightweight.

I have a half-finished patch of that but then all the un-extensibleness of
GstMiniObject frustrated me too much to continue that this week. I'll take a
look at finishing that next week by adding another allocation to each
miniobject as outlined above.

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