libffmpeg chromium crashes due to unaligned SSE accesses
Adrian Chadd
adrian.chadd at gmail.com
Sun Jun 22 07:21:55 UTC 2014
I finally tested this and I haven't seen any crashes so far.
Thanks!
Would you mind committing it?
-a
On 26 May 2014 13:48, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> 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