libffmpeg chromium crashes due to unaligned SSE accesses

[Dimitry Andric]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multimedia__ffmpeg-force-i386-stack-realign-1.diff
Type: application/octet-stream
Size: 1949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-chromium/attachments/20140513/b52e7e46/attachment.obj>
-------------- next part --------------

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-chromium/attachments/20140513/b52e7e46/attachment.sig>