libffmpeg chromium crashes due to unaligned SSE accesses

Fri May 16 20:26:07 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[continue top-posting ...]

Can you try the attached patch (i.e. put in files/ and rebuild chromium) ?
% patch < files/patch-third_party__ffmpeg__chromium*
% rm work/.configure_done* work/.build_done* work/.stage_done*
% make

The patch should be invoked on both gcc and clang builds, on amd64
systems this should not rebuild anything.

René

On 05/13/2014 00:08, Dimitry Andric 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
>>>>>>> 
>>>>> 
>>> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTdnRZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMDFBNzE2QjE2MkIwMEU1NUJFREVBMDVB
REJCRjg2MTBBMzc4OUI3AAoJEK27+GEKN4m3pO8P/j3N+F08rGR0EddqyIk0EckM
oP529QME5jfHe4st2L4YieROGyTZ52f9FgorcDXja0oKlmqdXQ0gLxRgthHkJNOw
UWmLP8x4Dfe8h3lY2BwXijGq9kdu1EV9bXucQpQuArYCvAVqgHC3ZuH9y2E5xmGo
xHJrRlelZ8cXUVXmOsBhtTk7Vs13Hj//GLUGUI70M9Uwi3nr7+ZV1/2okmnqsFtO
WCiLw8ErRjBZ0dn/xlRdTEpQbzFyCohjKxjGRyrHo3BQcGth6WTvKIQvO7mzxxgC
vZr50NNjAHTGYlJZVbyooA28pO2NKl8ykBMIDnxAMTWN5oHfYH2HNOgWq+UWpwRB
ukPNrnT0YiOK9k00HKuqMl3v1vupXP95nbEL4xHAirE1xZV7dzoPh/7aN6qfpGS8
K7Azl5/2ADxBh73z8xdPHVPTX/4QcRg7jeSUwkTkRAcj24LEAxWlpgo34Okwa1If
wVxjPFqjHOyAT29sLY50SpByqe/uVMzDKsbLEHI9F8u96MeAwbiDDZhq+DSH10uU
0OqcK9KbdkQrCjbmBxL0mIb6ziDtEhgs0gRnT8cMgGgLvbtLQRCqJT4D6djzyevS
i1/hv+Rk8mdu8WlJ7J/SpxelBijxZse/E2JCWwt7XaNjHRT/9VI1o0KxBBwPvWTE
rPYEDE/EVtis3SKWQ32o
=ifpL
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-third_party__ffmpeg__chromium__config__Chromium__linux__ia32__config.h.sig
Type: application/octet-stream
Size: 639 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-chromium/attachments/20140516/e21d4b8e/attachment.obj>