[FFmpeg-devel] [PATCH][VAAPI][2/6] Add common data structures and helpers (take 3)

Gwenole Beauchesne gbeauchesne
Sun Mar 8 09:55:28 CET 2009


Le 7 mars 09 ? 21:01, Michael Niedermayer a ?crit :

>>>> +    else {
>>>> +        if (rds->slice_data_size + size > rds-
>>>>> slice_data_size_max) {
>>>> +            rds->slice_data_size_max += size;
>>>> +            rds->slice_data = av_realloc(rds->slice_data, rds-
>>>>> slice_data_size_max);
>>>> +            if (!rds->slice_data)
>>>> +                return -1;
>>>> +        }
>>>
>>> memleak and possibly exploitable, at least the values are left in
>>> inconsistant
>>> state.
>>
>> Could you please explain the memleak part? If rds->slice_data ==
>> NULL,  the memory is gone anyway.
>
> realloc() returning NULL means the original is still there just that
> it failed re allocating it

7.20.3.4 indeed confirms what you say but I couldn't find a single  
code in lavc operating that way:
new_buffer = av_*_realloc(buffer, new_size);
if (!new_buffer) {
     av_freep(&buffer);
     // do whatever else/return -1
}
buffer = new_buffer;

would this be what you had in mind?

> also glibc memcpy() is shit, even more so for copying ito non system  
> memory
> you should maybe look at mplayer which has some memcpy written for  
> that.

Hmmm, I think this statement no longer holds for some years now. ;-)  
Even Agner's doesn't bring that much, if any performance gain.  
Besides, system libcs generally provide the best memcpy() tuned for  
the underlying processor and memory hierarchy (caches geometry et  
al.). This is true for Apple's (commpage provided functions) and even  
glibc, though depending on several factors (distributor, architecture).



More information about the ffmpeg-devel mailing list