[FFmpeg-devel] [PATCH] lavu/buffer: add release function
Lukasz Marek
lukasz.m.luki at gmail.com
Sun Mar 2 19:06:18 CET 2014
On 02.03.2014 18:14, Michael Niedermayer wrote:
> 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
Yes, I agree now it may be danger at this version.
Remove it from 2.2 branch too, BTW.
--
Best Regards,
Lukasz Marek
I may be drunk, Miss, but in the morning I will be sober and you will
still be ugly. - Winston Churchill
More information about the ffmpeg-devel
mailing list