Bug#627133: melt: segfault with framebuffer
Samuel Mimram
Version: 0.7.2-2
Severity: normal
Hi,
I got a segfault with openshot. After investigating a bit further it turns out that I get the same problem when running "melt framebuffer:x.avi?2" (which is used by openshot). However, if I specify a profile, for instance "melt -profile square_ntsc framebuffer:x.avi?2", the video plays at double speed as expected. Is melt supposed to crash when framebuffer is used without specifying a profile?...
For info, the stacktrace is
0x00007fffe15955ac in filter_line_sse2 (mode=0, dst=0x7fffc8629380 "",
prev=0x7fffc8429320 "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
cur=0x7fffc8369300 "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262
\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
next=0x7fffc8529350 "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"..., w=<value optimized out>, refs=640, parity=0)
at vf_yadif_template.h:234
234 vf_yadif_template.h: No such file or directory.
in vf_yadif_template.h
Thanks!
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages melt depends on:
ii libc6 2.13-4 Embedded GNU C Library: Shared lib
ii libmlt-data 1:0.7.2-0.0 multimedia framework (data)
ii libmlt4 1:0.7.2-0.0 multimedia framework (runtime)
melt recommends no packages.
melt suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Patrick Matthäi
But could you please retry it with a not-hardened build by rebuilding the
package without the hardening-wrapper build-dependency and commenting out
the deb_build_hardening environment export at the beginning of
debian/rules and see if it still occurs? Thanks!
Samuel Mimram
I hope that you had a good night ;)
I can confirm that the bug still occurs with a non-hardened package (rebuilt following your instructions).
++
Sam.
Samuel Mimram
I can confirm that the bug still occurs with a non-hardened package (rebuilt following your instructions).
For info, the full stacktrace is:
#0 0x00007fffe5ec54cd in filter_line_sse2 (mode=0, dst=0x7fffde5fb7a0 "",
prev=0x7fffde6fd7a0 "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
cur=0x7ffff7e567a0 "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
next=0x7fffde67c7a0 "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
dst=0x7fffde5fb020 "\214\214\215\217\220\221\222\223\224\224\224\224\224\223\223\223\227\227\227\230\231\232\232\232\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\241\241\242\243\243\244\245\245\246\247\247\250\251\252\253\253\251\251\251\251\251\251\251\251\254\253\253\252\251\250\247\247\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\257\257\257\257\257\257\257\257\257\257\257\257\257\257\257\257\261\261\261\261\261\261\261\261\260\260\260\260\260\260\260\260\256\256\256\256\256\256\256\256\257\256\256\255\254\254\253\253\254\254\254\254\254\254\254\254\252\252\252\252\252\252\252\252\254\253\251\247\247\247\250\251\246\246\247\247\250\251\251\252\250\250\247\246\246\245\244\244\246\245\245\244\243\243\242\242"...,
dst_stride=640, prev0=<value optimized out>,
cur0=0x7ffff7e56020 "\214\214\215\217\220\221\222\223\224\224\224\224\224\223\223\223\227\227\227\230\231\232\232\232\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\241\241\242\243\243\244\245\245\246\247\247\250\251\252\253\253\251\251\251\251\251\251\251\251\254\253\253\252\251\250\247\247\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\257\257\257\257\257\257\257\257\257\257\257\257\257\257\257\257\261\261\261\261\261\261\261\261\260\260\260\260\260\260\260\260\256\256\256\256\256\256\256\256\257\256\256\255\254\254\253\253\254\254\254\254\254\254\254\254\252\252\252\252\252\252\252\252\254\253\251\247\247\247\250\251\246\246\247\247\250\251\251\252\250\250\247\246\246\245\244\244\246\245\245\244\243\243\242\242"...,
next0=<value optimized out>, refs=640, w=640, h=480, parity=0, tff=0, cpu=3) at yadif.c:397
#2 0x00007fffe5ec6b1e in deinterlace_yadif (frame=<value optimized out>, filter=<value optimized out>, image=0x7fffffffe288,
format=0x7fffffffe294, width=0x7fffffffdfb4, height=0x7fffffffdfb8, mode=0) at filter_deinterlace.c:152
#3 0x00007fffe5ec6e65 in filter_get_image (this=0x70f660, image=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffdfb4,
height=0x7fffffffdfb8, writable=0) at filter_deinterlace.c:220
#4 0x00007ffff7bc219a in mlt_frame_get_image (self=0x70f660, buffer=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffdfb4,
height=0x7fffffffdfb8, writable=0) at mlt_frame.c:453
#5 0x00007fffe446b615 in filter_get_image (this=0x70f660, image=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffe0d0,
height=0x7fffffffe0d4, writable=0) at filter_rescale.c:215
#6 0x00007ffff7bc219a in mlt_frame_get_image (self=0x70f660, buffer=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffe0d0,
height=0x7fffffffe0d4, writable=0) at mlt_frame.c:453
#7 0x00007fffe446bb12 in filter_get_image (this=0x70f660, image=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffe298,
height=0x7fffffffe29c, writable=0) at filter_resize.c:265
#8 0x00007ffff7bc219a in mlt_frame_get_image (self=0x70f660, buffer=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffe298,
height=0x7fffffffe29c, writable=0) at mlt_frame.c:453
#9 0x00007ffff7bd302b in producer_get_image (self=0x70f030, buffer=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffe298,
height=0x7fffffffe29c, writable=<value optimized out>) at mlt_tractor.c:275
#10 0x00007ffff7bc219a in mlt_frame_get_image (self=0x70f030, buffer=0x7fffffffe288, format=0x7fffffffe294, width=0x7fffffffe298,
height=0x7fffffffe29c, writable=0) at mlt_frame.c:453
#11 0x0000000000402726 in guess_profile (argc=2, argv=0x7fffffffe3c8) at melt.c:356
#12 main (argc=2, argv=0x7fffffffe3c8) at melt.c:673
Patrick Matthäi
> On Wed, May 18, 2011 at 10:31 AM, Samuel Mimram <smi...@gmail.com
> <mailto:smi...@gmail.com>> wrote:
>
> I can confirm that the bug still occurs with a non-hardened package
> (rebuilt following your instructions).
>
>
> For info, the full stacktrace is:
>
> #0 0x00007fffe5ec54cd in filter_line_sse2 (mode=0, dst=0x7fffde5fb7a0 "",
> prev=0x7fffde6fd7a0
> "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
I see SSE2 foo, but this could not be the issue, because the i386
packages (with that I tested it these days) are build without any CPU
optimizations.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmat...@debian.org
pat...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
Samuel Mimram
Am 18.05.2011 21:22, schrieb Samuel Mimram:
> On Wed, May 18, 2011 at 10:31 AM, Samuel Mimram <smi...@gmail.com
> <mailto:smi...@gmail.com>> wrote:I see SSE2 foo, but this could not be the issue, because the i386
>
> I can confirm that the bug still occurs with a non-hardened package
> (rebuilt following your instructions).
>
>
> For info, the full stacktrace is:
>
> #0 0x00007fffe5ec54cd in filter_line_sse2 (mode=0, dst=0x7fffde5fb7a0 "",
> prev=0x7fffde6fd7a0
> "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
packages (with that I tested it these days) are build without any CPU
optimizations.
Well, I'm on amd64 and SSE2 seems to be enabled here (I see -DUSE_SSE2 in build logs...).
Samuel Mimram
optimizations.
Well, I'm on amd64 and SSE2 seems to be enabled here (I see -DUSE_SSE2 in build logs...).
Even better, when I add --disable-sse2 to the configure options on amd64, the problem vanishes!
Patrick Matthäi
> On Wed, May 18, 2011 at 10:18 PM, Patrick Matthäi <pmat...@debian.org
> <mailto:pmat...@debian.org>> wrote:
>
> Am 18.05.2011 22:12, schrieb Samuel Mimram:
> > Well, I'm on amd64 and SSE2 seems to be enabled here (I see
> > -DUSE_SSE2 in build logs...).
> >
> >
> > Even better, when I add --disable-sse2 to the configure options on
> > amd64, the problem vanishes!
> >
>
> and i386 is build without optimiziations (e.g. --disable-sse2 is
> passed), so this does not make sense :/
>
>
> Aren't you confusing with the other bug I reported (#627122)?
Oh right sorry for the noise :/
Samuel Mimram
Am 18.05.2011 22:12, schrieb Samuel Mimram:
> Well, I'm on amd64 and SSE2 seems to be enabled here (I see
> -DUSE_SSE2 in build logs...).
>
>
> Even better, when I add --disable-sse2 to the configure options on
> amd64, the problem vanishes!
>
Well I have got amd64 and i386 and it is reproduceable on both system
and i386 is build without optimiziations (e.g. --disable-sse2 is
passed), so this does not make sense :/
Patrick Matthäi
> -DUSE_SSE2 in build logs...).
>
>
> Even better, when I add --disable-sse2 to the configure options on
> amd64, the problem vanishes!
>
Well I have got amd64 and i386 and it is reproduceable on both system
and i386 is build without optimiziations (e.g. --disable-sse2 is
passed), so this does not make sense :/
--
Dan Dennedy
>
>
> On Wed, May 18, 2011 at 10:09 PM, Samuel Mimram <smi...@gmail.com> wrote:
>>
>> On Wed, May 18, 2011 at 9:25 PM, Patrick Matthäi <pmat...@debian.org> wrote:
>>>
>>> Am 18.05.2011 21:22, schrieb Samuel Mimram:
>>> > On Wed, May 18, 2011 at 10:31 AM, Samuel Mimram <smi...@gmail.com
>>> > <mailto:smi...@gmail.com>> wrote:
>>> >
>>> > I can confirm that the bug still occurs with a non-hardened package
>>> > (rebuilt following your instructions).
>>> >
>>> >
>>> > For info, the full stacktrace is:
>>> >
>>> > #0 0x00007fffe5ec54cd in filter_line_sse2 (mode=0, dst=0x7fffde5fb7a0 "",
>>> > prev=0x7fffde6fd7a0
>>> > "\207\207\210\212\213\214\215\215\220\220\220\221\222\222\222\223\224\224\225\225\226\227\227\230\233\233\234\234\235\236\236\237\240\240\241\241\242\243\243\244\243\244\244\245\246\246\247\247\252\251\251\250\247\246\245\245\251\251\251\251\251\251\251\251\255\255\255\255\255\254\254\254\255\255\255\255\255\255\255\255\257\257\257\257\257\257\257\257\260\260\260\260\260\260\260\260\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\261\263\263\263\263\263\263\263\263\262\262\262\262\262\262\262\262\260\260\260\260\260\260\260\260\261\261\260\260\257\256\256\255\256\256\256\256\256\256\256\256\254\254\254\254\254\254\254\254\257\256\254\252\251\252\252\253\250\251\251\252\253\253\254\254\255\255\254\254\253\252\252\251\250\250\247\247\246\245\245\244"...,
>>>
>>> I see SSE2 foo, but this could not be the issue, because the i386
>>> packages (with that I tested it these days) are build without any CPU
>>>
>>
>> Well, I'm on amd64 and SSE2 seems to be enabled here (I see -DUSE_SSE2 in build logs...).
>
> Even better, when I add --disable-sse2 to the configure options on amd64, the problem vanishes!
>
I reproduced this on my Arch Linux box using gcc v4.6. Some
optimizations in -O1 and -O2 cause this SSE2 code to fail. I did
bisection testing of all of the specific options these enable and
isolated them:
# Since gcc 4.6, this optimization enabled with -O1 causes
filter_line_sse2 to crash.
echo "OPTIMISATIONS+=-fno-tree-dominator-opts"
# Since gcc 4.6, this optimization enabled with -O2 causes
filter_line_sse2 to crash.
echo "OPTIMISATIONS+=-fno-tree-pre"
The solution is in the next version or you can configure with
--disable-sse2 since only the YADIF deinterlacer uses SSE2 and it also
has a SSE version that still works.
--
+-DRD-+
Samuel Mimram
Thanks! This is great to see so reactive open-source projects!
++
Sam.