Your message dated Sun, 29 May 2011 17:51:44 +0200
with message-id <[email protected]>
and subject line Re: [Mlt-devel] Bug#627133: melt: segfault with framebuffer
has caused the Debian Bug report #627133,
regarding melt: segfault with framebuffer
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
627133: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627133
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: melt
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
--- End Message ---
--- Begin Message ---
Version: 0.7.2+git20110529-1
narf I forget Close: in the changelog :)
Am 22.05.2011 22:04, schrieb Samuel Mimram:
> On Sun, May 22, 2011 at 8:50 PM, Dan Dennedy <[email protected]
> <mailto:[email protected]>> wrote:
>
> On Wed, May 18, 2011 at 1:12 PM, Samuel Mimram <[email protected]
> <mailto:[email protected]>> wrote:
> >
> >
> > On Wed, May 18, 2011 at 10:09 PM, Samuel Mimram <[email protected]
> <mailto:[email protected]>> wrote:
> >>
> >> On Wed, May 18, 2011 at 9:25 PM, Patrick Matthäi
> <[email protected] <mailto:[email protected]>> wrote:
> >>>
> >>> Am 18.05.2011 21:22, schrieb Samuel Mimram:
> >>> > On Wed, May 18, 2011 at 10:31 AM, Samuel Mimram
> <[email protected] <mailto:[email protected]>
> >>> > <mailto:[email protected] <mailto:[email protected]>>> 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.
> >>
> >> 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.
>
>
> Thanks! This is great to see so reactive open-source projects!
>
> ++
>
> Sam.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: [email protected]
[email protected]
Comment:
Always if we think we are right,
we were maybe wrong.
*/
--- End Message ---
