On Thu, Jan 5, 2012 at 4:18 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Thu, Jan 5, 2012 at 6:54 AM, Reinhard Tartler <siret...@tauware.de> wrote: >> On Do, Jan 05, 2012 at 15:43:40 (CET), Ronald S. Bultje wrote: >>> 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? > > See earlier thread: > > [PATCH] swscale: fix crash in fast_bilinear code when compiled with > -mred-zone.
Måns claimed the code to be incorrect without explaining what the problem is. However, it does seem to fix at least some cases. -- regards, Reinhard _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
