libffmpeg chromium crashes due to unaligned SSE accesses
Adrian Chadd
adrian.chadd at gmail.com
Mon May 26 20:48:03 UTC 2014
I'll double check soon.
Please realize that a lot of these laptops I have aren't built for doing
large scale package building. I don't have anything with lots of ram and
disks. I run almost exclusively binary packages now days.
Adrian
On May 26, 2014 7:03 AM, "René Ladan" <rene at freebsd.org> wrote:
> Hi,
>
> you mean that the patch I made out of Dimitrys patch works fine?
>
> René
>
> On 05/20/2014 18:28, Adrian Chadd wrote:
> > Hi,
> >
> > So whose arm should I twist to get this stuff committed to both the
> > libffmpeg and chromium ports?
> >
> >
> > -a
> >
> >
> > On 12 May 2014 15:08, Dimitry Andric <dim at freebsd.org> wrote:
> >> Since I still can't reproduce any crashes with the current
> multimedia/ffmpeg port, I made this patch for you to try out. I think
> something similar can be applied to the version of ffmpeg embedded in
> chromium, but that seems to use yet another NIH build system of the month.
> This is probably something for the chromium maintainers to figure out.
> >>
> >> The basic idea is to to add the following flags, if building with clang
> on i386-freebsd (ffmpeg confusingly calls this x86_32, which is something
> totally different in the rest of the world):
> >>
> >> -mstack-alignment=16
> >> -mstackrealign
> >>
> >> The former forces clang to assume 16-byte stack alignment, even on
> i386, and the latter forces a realignment to 16 bytes at the entry point of
> each function. Something similar is probably needed for gcc, but alignment
> is broken there anyway...
> >>
> >> -Dimitry
> >>
> >>
> >> On 09 May 2014, at 23:53, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> >>
> >>> Just using it for a day or so. You'll stumble across things like
> >>> moving images in facebook, embedded youtube images, etc, that combined
> >>> with whatever the stack alignment is, results in a crash.
> >>>
> >>> I've posted a coredump backtrace. I can generate chromium coredumps on
> >>> my i386 laptop many, many times a day. It's actually happening.
> >>>
> >>>
> >>> -a
> >>>
> >>>
> >>> On 9 May 2014 14:49, Dimitry Andric <dim at freebsd.org> wrote:
> >>>> I think you are referring to the --enable-memalign-hack option passed
> to ffmpeg's configure script? That is something related to
> posix_memalign(), not to stack alignment.
> >>>>
> >>>> That said, I just built the chromium port with its default options,
> and while I cannot get it to crash, I cannot get it to display any video
> either. It must be because I'm running a VMware guest, and chromium does
> not cope with that too well (Firefox seems to work much better, though not
> terribly fast).
> >>>>
> >>>> What kind of activity should make chromium crash? Just running it,
> or displaying a certain website?
> >>>>
> >>>> -Dimitry
> >>>>
> >>>> On 09 May 2014, at 21:11, Adrian Chadd <adrian.chadd at gmail.com>
> wrote:
> >>>>
> >>>>> There's an alignment hack option in the ffmpeg port though. It's not
> a
> >>>>> cflags thing, it's a ./configure thing.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -a
> >>>>>
> >>>>>
> >>>>> On 9 May 2014 11:40, Dimitry Andric <dim at freebsd.org> wrote:
> >>>>>> I just tried building multimedia/ffmpeg on i386-freebsd11, with the
> default port settings, and it seems to work just fine. I tried transcoding
> a few files, and there were no stack alignment problems or SIGBUSes.
> >>>>>>
> >>>>>> Looking at the build logs, I see
> >>>>>>
> >>>>>> C compiler cc
> >>>>>> ARCH x86 (generic)
> >>>>>> big-endian no
> >>>>>> runtime cpu detection yes
> >>>>>> yasm yes
> >>>>>> MMX enabled yes
> >>>>>> MMXEXT enabled yes
> >>>>>> 3DNow! enabled yes
> >>>>>> 3DNow! extended enabled yes
> >>>>>> SSE enabled yes
> >>>>>> SSSE3 enabled yes
> >>>>>> AVX enabled yes
> >>>>>> FMA4 enabled yes
> >>>>>> i686 features enabled yes
> >>>>>> CMOV is fast no
> >>>>>> EBX available yes
> >>>>>> EBP available yes
> >>>>>> ...
> >>>>>>
> >>>>>> The command line flags used for compilation (wrapped for clarity)
> don't seem to include specific ones that change stack alignment behavior:
> >>>>>>
> >>>>>> cc \
> >>>>>> -I. \
> >>>>>> -I./ \
> >>>>>> -DLIBICONV_PLUG \
> >>>>>> -D_ISOC99_SOURCE \
> >>>>>> -D_FILE_OFFSET_BITS=64 \
> >>>>>> -D_LARGEFILE_SOURCE \
> >>>>>> -DHAVE_AV_CONFIG_H \
> >>>>>> -O2 \
> >>>>>> -pipe \
> >>>>>> -march=corei7 \
> >>>>>> -DLIBICONV_PLUG \
> >>>>>> -fno-strict-aliasing \
> >>>>>> -msse \
> >>>>>> -I/usr/local/include/vorbis \
> >>>>>> -I/usr/local/include \
> >>>>>> -std=c99 \
> >>>>>> -fomit-frame-pointer \
> >>>>>> -I/usr/local/include \
> >>>>>> -I/usr/local/include/freetype2 \
> >>>>>> -I/usr/local/include/libpng15 \
> >>>>>> -I/usr/local/include \
> >>>>>> -I/usr/local/include/p11-kit-1 \
> >>>>>> -I/usr/local/include/freetype2 \
> >>>>>> -I/usr/local/include/libpng15 \
> >>>>>> -I/usr/local/include/opencv \
> >>>>>> -I/usr/local/include \
> >>>>>> -I/usr/local/include/schroedinger-1.0 \
> >>>>>> -I/usr/local/include/orc-0.4 \
> >>>>>> -Wdeclaration-after-statement \
> >>>>>> -Wall \
> >>>>>> -Wno-parentheses \
> >>>>>> -Wno-switch \
> >>>>>> -Wno-format-zero-length \
> >>>>>> -Wdisabled-optimization \
> >>>>>> -Wpointer-arith \
> >>>>>> -Wredundant-decls \
> >>>>>> -Wno-pointer-sign \
> >>>>>> -Wwrite-strings \
> >>>>>> -Wtype-limits \
> >>>>>> -Wundef \
> >>>>>> -Wmissing-prototypes \
> >>>>>> -Wno-pointer-to-int-cast \
> >>>>>> -Wstrict-prototypes \
> >>>>>> -O3 \
> >>>>>> -fno-math-errno \
> >>>>>> -fno-signed-zeros \
> >>>>>> -Qunused-arguments \
> >>>>>> -Werror=implicit-function-declaration \
> >>>>>> -Werror=missing-prototypes \
> >>>>>> -Werror=return-type \
> >>>>>> -MMD \
> >>>>>> -c \
> >>>>>>
> >>>>>> I'll build chromium with the default options, and see what happens.
> >>>>>>
> >>>>>> -Dimitry
> >>>>>>
> >>>>>> On 09 May 2014, at 19:09, Adrian Chadd <adrian.chadd at gmail.com>
> wrote:
> >>>>>>
> >>>>>>> What's the magic to get the normal ffmpeg port to work right?
> >>>>>>>
> >>>>>>>
> >>>>>>> -a
> >>>>>>>
> >>>>>>>
> >>>>>>> On 9 May 2014 10:05, Dimitry Andric <dim at freebsd.org> wrote:
> >>>>>>>> On 09 May 2014, at 18:42, Adrian Chadd <adrian.chadd at gmail.com>
> wrote:
> >>>>>>>>> On 9 May 2014 06:50, Pedro Giffuni <pfg at freebsd.org> wrote:
> >>>>>>>>>> Hello;
> >>>>>>>>>>
> >>>>>>>>>> El 5/9/2014 5:56 AM, Adrian Chadd escribió:
> >>>>>>>>>>
> >>>>>>>>>>> Hi guys,
> >>>>>>>>>>>
> >>>>>>>>>>> I filed a PR recently with chromium crashes in its internal
> libffmpeg:
> >>>>>>>>>>>
> >>>>>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=189317
> >>>>>>>>>>>
> >>>>>>>>>>> What do you two think? It's that Linux 16 byte alignment on
> i386 issue
> >>>>>>>>>>> that has been creeping up every few years.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Ouch, that's clang, right?
> >>>>>>>>>
> >>>>>>>>> I gather so? It's whatever the binary package building cluster is
> >>>>>>>>> using. I think it's clang for i386.
> >>>>>>>>
> >>>>>>>> For 10.x and 11.x, that should indeed be clang.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I recently brought this from OpenBSD, no idea if it's related:
> >>>>>>>>>>
> >>>>>>>>>> http://svnweb.freebsd.org/base?view=revision&revision=265231
> >>>>>>>>>>
> >>>>>>>>>> For now I guess we should just patch the libffmpeg port like
> the NetBSD guys
> >>>>>>>>>> did.
> >>>>>>>>>
> >>>>>>>>> Kind of? The x86-64 ABI requires 16 byte alignment for a lot of
> stuff.
> >>>>>>>>> The i386 32 bit ABI doesn't require 16 byte alignment as per
> >>>>>>>>> everything pre-Linux-in-2005ish. Linux / gcc flipped the "i386
> == 16
> >>>>>>>>> byte alignment now" switch. I vaguely recall that they made
> >>>>>>>>> _everything_ 16 byte aligned but I can't be sure.
> >>>>>>>>
> >>>>>>>> Yes, actually the gcc guys just flipped the switch somewhere in
> 2008,
> >>>>>>>> without any consideration for backwards compatibility, and this
> lead to
> >>>>>>>> quite a bit of wailing, but they WONTFIXed it anyway:
> >>>>>>>>
> >>>>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
> >>>>>>>>
> >>>>>>>> So the problem is that there are quite a lot of projects that
> simply
> >>>>>>>> assume everything on x86 has 16-byte aligned stacks, and you can
> use SSE
> >>>>>>>> instructions that require strict alignment (e.g. movaps) on any
> random
> >>>>>>>> stack-allocated variable. Obviously, on i386-freebsd, that is
> not the
> >>>>>>>> case, as we still maintain the old SysV 4-byte alignment.
> >>>>>>>>
> >>>>>>>> FFmpeg is one of those projects that assumes 16-byte alignment,
> and also
> >>>>>>>> has a lot of hand-written SSE assembly, either inline or in
> separate
> >>>>>>>> yasm sources. The brute-force way of fixing trouble with
> alignment is
> >>>>>>>> to add -mstackrealign to CFLAGS, but I'm not sure if that is the
> correct
> >>>>>>>> solution here.
> >>>>>>>>
> >>>>>>>> As far as I know, the current FFmpeg port seems to work OK on
> >>>>>>>> i386-freebsd, so maybe it could be enough to fix up the Chromium
> version
> >>>>>>>> of FFmpeg in a similar manner as the regular FFmpeg port? I'm
> not sure
> >>>>>>>> I will have enough time to have look at it soon, though...
> >>>>>>>>
> >>>>>>>> -Dimitry
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> >>
> > _______________________________________________
> > freebsd-chromium at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-chromium
> > To unsubscribe, send any mail to "
> freebsd-chromium-unsubscribe at freebsd.org"
> >
>
>
More information about the freebsd-chromium
mailing list