On Do, Jan 05, 2012 at 15:43:40 (CET), Ronald S. Bultje wrote: > Hi, > > On Thu, Jan 5, 2012 at 6:42 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: >> On Thu, Jan 5, 2012 at 5:51 AM, Reinhard Tartler <siret...@gmail.com> wrote: >>> On Sun, Dec 25, 2011 at 9:57 PM, Reinhard Tartler <siret...@gmail.com> >>> wrote: >>>> On Mon, Nov 7, 2011 at 10:01 PM, Ronald S. Bultje <rsbul...@gmail.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> On Mon, Nov 7, 2011 at 12:46 PM, Reinhard Tartler <siret...@tauware.de> >>>>> wrote: >>>>>> On Mo, Nov 07, 2011 at 18:20:50 (CET), Måns Rullgård wrote: >>>>>> >>>>>>> Reinhard Tartler <siret...@tauware.de> 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. >>>>>> >>>>>> That sounds pretty plausible. >>>>>> >>>>>> To make matters more complicated, I've tried disabling the MMX2 version >>>>>> of hyscale_fast with this patch: >>>>>> >>>>>> diff --git a/libswscale/x86/swscale_template.c >>>>>> b/libswscale/x86/swscale_template.c >>>>>> index 5e7df5c..b7a75b1 100644 >>>>>> --- a/libswscale/x86/swscale_template.c >>>>>> +++ b/libswscale/x86/swscale_template.c >>>>>> @@ -1843,7 +1843,7 @@ static av_cold void >>>>>> RENAME(sws_init_swScale)(SwsContext *c) >>>>>> if (c->srcBpc == 8 && c->dstBpc <= 10) { >>>>>> // Use the new MMX scaler if the MMX2 one can't be used (it is >>>>>> faster than the x86 ASM one). >>>>>> #if COMPILE_TEMPLATE_MMX2 >>>>>> - if (c->flags & SWS_FAST_BILINEAR && c->canMMX2BeUsed) >>>>>> + if (c->flags & SWS_FAST_BILINEAR && c->canMMX2BeUsed && 0) >>>>>> { >>>>>> c->hyscale_fast = RENAME(hyscale_fast); >>>>>> c->hcscale_fast = RENAME(hcscale_fast); >>>>>> >>>>>> AFAIUI, this makes swscale fallback to the slower hyScale() function and >>>>>> avoid this buggy implementation. Unfortunately, I get another >>>>>> segmentation fault here: >>>>> >>>>> That's not right, scaling coefficients are different so you need to >>>>> account for that. >>>>> >>>>> I'll have a look at this... I'm not against removing hscale_fast >>>>> altogether, including the scale coefficient specialcase handling etc. >>>> >>>> any news on this? did you have a chance to look at this? >>> >>> ping? >> >> As said on IRC, disable the code on x86-64 for now. I've had a look >> and am working on porting all inline asm (including this) to yasm >> (which means I can manually control redzone'ness), but it's not ready >> yet. > > Btw I did send a patch earlier that prevented redzone from killing > this, it is hacky but solves the crash. We can apply that but Mans had > objections. I feel it should perhaps be applied as a temporary > solution anyway before I finish all this porting.
I'd very much welcome such a temporary solution, because I expect this to be way easier to backport to 0.7 than the full porting. Måns, would you agree with this approach? Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
