libffmpeg chromium crashes due to unaligned SSE accesses
Adrian Chadd
adrian.chadd at gmail.com
Fri May 9 21:53:23 UTC 2014
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
>>>>>
>>>
>
More information about the freebsd-chromium
mailing list