"Ronald S. Bultje" <[email protected]> writes: > Hi, > > 2011/11/7 Måns Rullgård <[email protected]>: >> "Ronald S. Bultje" <[email protected]> writes: >> >>> 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. :-). >> >> It's calling some generated code. So what? Use a function pointer. > > Ugliest version of emulating pmaddubsw ever? That's essentially what it is...
Option 4: delete it -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
