On Mo, Nov 07, 2011 at 18:20:50 (CET), Måns Rullgård wrote:
> 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.
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:
Starting program: /srv/scratch/libav/libav/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
[Thread debugging using libthread_db enabled]
ffmpeg version v0.7-1733-g18bc1b1, Copyright (c) 2000-2011 the Libav developers
built on Nov 7 2011 21:18:40 with gcc 4.6.1
[...]
[amv @ 0x1329760] marker parser used 3372 bytes (26973 bits)
[amv @ 0x1329760] marker=d9 avail_size_in_buf=0
[amv @ 0x1329760] mjpeg decode frame unused 0 bytes
Program received signal SIGSEGV, Segmentation fault.
0x00000000009c1e82 in yuv2rgb_write (hasAlpha=0, target=PIX_FMT_RGB24,
y=<optimized out>, _b=0x132aa07, _g=0x132a9d4, _r=0x0, A2=0, A1=0,
Y2=<optimized out>, Y1=-29, i=<optimized out>, _dest=<optimized out>,
U=<optimized out>, V=<optimized out>) at libswscale/swscale.c:957
957 dest[i * 6 + 0] = r_b[Y1];
(gdb) bt
#0 0x00000000009c1e82 in yuv2rgb_write (hasAlpha=0, target=PIX_FMT_RGB24,
y=<optimized out>, _b=0x132aa07, _g=0x132a9d4, _r=0x0, A2=0, A1=0,
Y2=<optimized out>, Y1=-29, i=<optimized out>, _dest=<optimized out>,
U=<optimized out>, V=<optimized out>) at libswscale/swscale.c:957
#1 yuv2rgb_2_c_template (hasAlpha=0, target=PIX_FMT_RGB24, y=<optimized out>,
uvalpha=0, yalpha=0, dstW=320, dest=<optimized out>,
abuf=<optimized out>, vbuf=<optimized out>, ubuf=<optimized out>,
buf=<optimized out>, c=0x133d520) at libswscale/swscale.c:1125
#2 yuv2rgb24_2_c (c=0x133d520, buf=<optimized out>, ubuf=<optimized out>,
vbuf=<optimized out>, abuf=<optimized out>, dest=<optimized out>,
dstW=320, yalpha=0, uvalpha=0, y=0) at libswscale/swscale.c:1225
#3 0x00000000009ca4b6 in swScale (c=0x133d520, src=<optimized out>,
srcStride=<optimized out>, srcSliceY=0, srcSliceH=120, dst=0x7fffffffc9a0,
dstStride=0x7fffffffc9d0) at libswscale/swscale.c:2531
#4 0x00000000009b11bf in sws_scale (c=0x133d520, srcSlice=<optimized out>,
srcStride=<optimized out>, srcSliceY=0, srcSliceH=<optimized out>,
dst=<optimized out>, dstStride=0x1329608) at
libswscale/swscale_unscaled.c:913
#5 0x000000000045094c in draw_slice (link=0x132a640, y=<optimized out>,
h=<optimized out>, slice_dir=1) at libavfilter/vf_scale.c:279
#6 0x0000000000445b74 in avfilter_draw_slice (link=0x132a640, y=0, h=120,
slice_dir=1) at libavfilter/avfilter.c:484
#7 0x0000000000454069 in request_frame (link=0x132a640) at
libavfilter/vsrc_buffer.c:141
#8 0x0000000000444c7b in avfilter_request_frame (link=<optimized out>) at
libavfilter/avfilter.c:373
Urm.
Another maybe interesting fact: ./configure --disable-optimizations does
not avoid the segfault, it remains to be present with a very similar
backtrace:
#0 0x00000000009cf397 in yuv2rgb_write (_dest=0x7ffff699b040 "", i=156, Y1=0,
Y2=0, U=-1, V=-1, A1=0, A2=0, _r=0x14018a0, _g=0x1401ad2,
_b=0xffffffa5ffffffa6, y=0, target=PIX_FMT_RGB24, hasAlpha=0) at
libswscale/swscale.c:959
#1 0x00000000009d0158 in yuv2rgb_2_c_template (c=0x1414520, buf=0x1401430,
ubuf=0x1405e70, vbuf=0x1405a90, abuf=0x0, dest=0x7ffff699b040 "",
dstW=640, yalpha=0, uvalpha=0, y=0, target=PIX_FMT_RGB24, hasAlpha=0) at
libswscale/swscale.c:1125
#2 0x00000000009d0bbb in yuv2rgb24_2_c (c=0x1414520, buf=0x1401430,
ubuf=0x1405e70, vbuf=0x1405a90, abuf=0x0, dest=0x7ffff699b040 "", dstW=640,
yalpha=0, uvalpha=0, y=0) at libswscale/swscale.c:1225
#3 0x00000000009d778f in swScale (c=0x1414520, src=0x7fffffffce50,
srcStride=0x7fffffffce90, srcSliceY=0, srcSliceH=120, dst=0x7fffffffce70,
dstStride=0x7fffffffcea0) at libswscale/swscale.c:2531
#4 0x00000000009b65a1 in sws_scale (c=0x1414520, srcSlice=0x7fffffffcf20,
srcStride=0x14051a8, srcSliceY=0, srcSliceH=120, dst=0x14005c8,
dstStride=0x1400608) at libswscale/swscale_unscaled.c:913
I note that in the first backtrace, the pointer _r, and in the second,
the pointer _b look suspicous.
./configure --disable-asm however does avoid it.
I also notice that valgrinds reports a number of invalid reads and write
in this testcase.
Regards,
Reinhard.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
