libffmpeg chromium crashes due to unaligned SSE accesses

[Adrian Chadd]

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
>>>
>