[FFmpeg-devel] [PATCH] lavu/buffer: add release function

Michael Niedermayer michaelni at gmx.at
Sun Mar 2 18:14:43 CET 2014

On Sun, Mar 02, 2014 at 05:48:11PM +0100, Lukasz Marek wrote:
> On 02.03.2014 17:14, Reimar Döffinger wrote:
> >On 28.02.2014, at 01:21, Lukasz Marek <lukasz.m.luki at gmail.com> wrote:
> >>>Keep in mind that a buffer can come from a user application. There is
> >>>no way you could free such a buffer correctly by destroying the buffer
> >>>reference and just returning the raw data.
> >>
> >This buffer might be allocated on some special hardware, and to allocate/lock or deallocate/unlock it you need to write some magic registers.
> >What happens if you use this function on such a buffer?
> >I can see only two things happen:
> >1) you call the custom free function, then all following code trying to use it will cause bus errors or worse
> I'm not sure I understand but if user operates on data they released
> with free function its just their fault. free() is dangerous in the
> same way.

> I assumed user will not release buffer if don't know how to delete it.

yes, also it would be possible to check if the free function points
to the standard free() based one in release buffer.
(this check is not 100% fool proof but it will only error onto the
 safe  side)
The code already contains support for using memdup which could be
used if its some fancy hw free

> >2) you don't call it. Then the external hardware will forever stay in a locked state which essentialy might mean it will hang
> >
> >The only way I can even see this working is if you assume that the buffer was allocated with an ordinary memory managment function like malloc, but that is nothing you can assume in general.
> If you mention such cases, I wonder what would happen when user ref
> buffer and make it writable and then second copy is freed with magic
> free function.
> Revering patch attached.

LGTM if you want to revert it / dont need it anymore


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140302/7810ff5a/attachment.asc>

More information about the ffmpeg-devel mailing list