[Webkit-unassigned] [Bug 213364] [GStreamer] gst_buffer_unmap: assertion 'GST_IS_BUFFER (buffer)' failed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=213364

--- Comment #3 from Xabier Rodríguez Calvar <calvaris at igalia.com> ---
(In reply to Philippe Normand from comment #2)
> Comment on attachment 404443 [details]
> Patch
> 
> This looks like a workaround for a bug in the InitData class. As the init
> data is quite small (IIRC), doesn't it pay off to have mapped buffer there?
> Can't we just copy it?

We could buy I don't think it is necessary because of I am going to comment below.

> Also I see the append() method assuming the m_payload
> is mutable, while the createSharedBuffer() has a comment mentioning it
> should be considered immutable.

The data inside the SharedBuffer should be immutable, not the SharedBuffer itself. That's why we assert on the mapping to be not WRITE. Actually, appending SharedBuffers as we do is quite efficient as no data is copied, only segments are appended or until it is read if needed.

About keeping the mapped buffer? It is already done, it leaves inside the DataSegment of the SharedBuffer.

GstMappedBuffer needs that he buffer outlives the mapped buffer of you will have the warning you're getting (which is a symptom of a deeper problem and can lead to unwanted reads). In many cases we just create the mapped buffer, use it and let it go. In this case, it is kept and as we're seeing in this case the buffer is not outliving the mapped buffer, which creates the problem.

Considering all this, I think reffing the buffer and guaranteeing it lives protected inside the mapped buffer is the right solution.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200721/01d01927/attachment-0001.htm>