Hi,

2011/11/7 Måns Rullgård <[email protected]>:
> Reinhard Tartler <[email protected]> writes:
>
>> tags 647824 upstream
>> stop
>>
>> On So, Nov 06, 2011 at 17:53:30 (CET), Harald Dunkel wrote:
>>
>>> Package: libav
>>> Version: 4:0.7.2-1
>>>
>>> If I build the current xbmc snapshot, then it dies at runtime when
>>> creating thumbnails for wmv files. See http://trac.xbmc.org/ticket/11789
>>> for more details
>>>
>>> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/134444
>>>
>>> provides a workaround. Do you think this could be included in the
>>> libav and libav-extra packages?
>>>
>>
>> That patch does not apply to Debian's libav package. In fact, it seems
>> that this bug is still present in the master branch.
>>
>> I was able to reproduce the segmentation fault using the following
>> command in libav *master* (inspired by
>> https://ffmpeg.org/trac/ffmpeg/ticket/397):
>>
>> ./ffmpeg -v 9 -loglevel 99 -i 
>> /srv/scratch/fate-suite/amv/MTV_high_res_320x240_sample_Penguin_Joke_MTV_from_WMV.amv
>>  -sws_flags fast_bilinear -vf "scale=640:480" -vframes 1 -vcodec png 
>> output.png
>>
>> Unforutnately, this (adapted) patch does not seem to fix the
>> segmentation fault:
>>
>> diff --git a/libswscale/x86/swscale_template.c 
>> b/libswscale/x86/swscale_template.c
>> index 5e7df5c..51ea303 100644
>> --- a/libswscale/x86/swscale_template.c
>> +++ b/libswscale/x86/swscale_template.c
>> @@ -1657,6 +1657,11 @@ static void RENAME(hyscale_fast)(SwsContext *c, 
>> int16_t *dst,
>>      DECLARE_ALIGNED(8, uint64_t, ebxsave);
>>  #endif
>>
>> +    // HACK: gcc 4.6 no longer decrements esp,
>> +    // use this to make it reserve space for the call
>> +    // return address
>> +    void *dummy;
>
> The real problem here comes from hiding a call inside inline asm.  On
> x86_64 leaf functions have a "red zone" of 128 bytes below the stack
> pointer which can be used for whatever the compiler feels like.  If the
> compiler has made use of this (gcc frequently does) and a call is
> injected with inline asm, any values kept in the red zone are destroyed.
>
> There are 3 solutions to this problem:
>
> 1. Do the calls in C.
> 2. Convert the function to yasm.
> 3. Manually protect the red zone in the inline asm.
>
> Option 3 is difficult to do if any asm parameters might reference the
> stack as is the case here.
>
> Why is this using asm at all?  It's only a few function calls.

You should check what it's calling. :-).

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to