Date: Tue, 13 May 2014 00:08:09 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: chromium@freebsd.org, Pedro Giffuni <pfg@freebsd.org> Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses Message-ID: <9BF4309C-9D56-467F-B882-754B8C94AA29@FreeBSD.org> In-Reply-To: <CAJ-Vmok9o5XLmybGrrjTpGpUAydRNMDek7WkjRbd7EJFXt2-Kg@mail.gmail.com> References: <CAJ-Vmo=C0dEhiK4O9Kunkg-P8ogSC_u_tsf_CQnUZMDvrXR-4g@mail.gmail.com> <536CDD30.40104@FreeBSD.org> <CAJ-Vmo=U3Ow3s728rXiEmfJZY%2BinkQRjiJ0bBvRmf0gALaCeew@mail.gmail.com> <7C272AE1-BA6E-48A9-9662-79B1030D0903@FreeBSD.org> <CAJ-VmonLr6m1c-XX-cB-LiQT0JtoGv97dd6VHzYZPCC3hCxreQ@mail.gmail.com> <9810619D-DF65-4A4F-9720-B22DC791EA65@FreeBSD.org> <CAJ-VmoknOe8d9H5o8D1XMWn%2Bq%2B_aJ-B46URwkOsnVkWAXEhamw@mail.gmail.com> <FC7C93ED-F20B-4999-BF84-280F9DA9926A@FreeBSD.org> <CAJ-Vmok9o5XLmybGrrjTpGpUAydRNMDek7WkjRbd7EJFXt2-Kg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_8352BF35-F254-4160-B3F6-D6A62FB167B5
Content-Type: multipart/mixed;
boundary="Apple-Mail=_DB0D4E9F-E99E-4144-AB92-39CA05FD7424"
--Apple-Mail=_DB0D4E9F-E99E-4144-AB92-39CA05FD7424
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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=3D16
-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
--Apple-Mail=_DB0D4E9F-E99E-4144-AB92-39CA05FD7424
Content-Disposition: attachment;
filename=multimedia__ffmpeg-force-i386-stack-realign-1.diff
Content-Type: application/octet-stream;
name="multimedia__ffmpeg-force-i386-stack-realign-1.diff"
Content-Transfer-Encoding: 7bit
Index: multimedia/ffmpeg/files/patch-configure
===================================================================
--- multimedia/ffmpeg/files/patch-configure (revision 353801)
+++ multimedia/ffmpeg/files/patch-configure (working copy)
@@ -1,6 +1,6 @@
--- configure.orig
+++ configure
-@@ -2147,7 +2147,7 @@ yasmexe_default="yasm"
+@@ -2316,7 +2316,7 @@ yasmexe_default="yasm"
nogas=":"
# machine
@@ -9,7 +9,7 @@
cpu="generic"
# OS
-@@ -3991,10 +3991,10 @@ perl --version > /dev/null 2>&1 && enabl
+@@ -4349,10 +4349,10 @@ perl --version > /dev/null 2>&1 && enabl
pod2man --help > /dev/null 2>&1 && enable pod2man || disable pod2man
rsync --help 2> /dev/null | grep -q 'contimeout' && enable rsync_contimeout || disable rsync_contimeout
@@ -24,7 +24,20 @@
check_header sys/videoio.h
-@@ -4373,7 +4373,7 @@ ifndef MAIN_MAKEFILE
+@@ -4534,7 +4534,11 @@ elif enabled gcc; then
+ elif enabled llvm_gcc; then
+ check_cflags -mllvm -stack-alignment=16
+ elif enabled clang; then
+- check_cflags -mllvm -stack-alignment=16
++ if enabled x86_32; then
++ check_cflags -mllvm -stack-alignment=16
++ check_cflags -mstack-alignment=16
++ check_cflags -mstackrealign
++ fi
+ check_cflags -Qunused-arguments
+ check_cflags -Werror=implicit-function-declaration
+ check_cflags -Werror=missing-prototypes
+@@ -4753,7 +4757,7 @@ ifndef MAIN_MAKEFILE
SRC_PATH:=\$(SRC_PATH:.%=..%)
endif
CC_IDENT=$cc_ident
@@ -33,7 +46,7 @@
CC=$cc
CXX=$cxx
AS=$as
-@@ -4555,7 +4555,7 @@ exec_prefix=\${prefix}
+@@ -4941,7 +4945,7 @@ exec_prefix=\${prefix}
libdir=$libdir
includedir=$incdir
@@ -42,7 +55,7 @@
Description: $comment
Version: $version
Requires: $(enabled shared || echo $requires)
-@@ -4569,10 +4569,10 @@ EOF
+@@ -4955,10 +4959,10 @@ EOF
mkdir -p doc/examples/pc-uninstalled
includedir=${source_path}
[ "$includedir" = . ] && includedir="\${pcfiledir}/../../.."
--Apple-Mail=_DB0D4E9F-E99E-4144-AB92-39CA05FD7424
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On 09 May 2014, at 23:53, Adrian Chadd <adrian.chadd@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.
>=20
> I've posted a coredump backtrace. I can generate chromium coredumps on
> my i386 laptop many, many times a day. It's actually happening.
>=20
>=20
> -a
>=20
>=20
> On 9 May 2014 14:49, Dimitry Andric <dim@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.
>>=20
>> 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).
>>=20
>> What kind of activity should make chromium crash? Just running it, =
or displaying a certain website?
>>=20
>> -Dimitry
>>=20
>> On 09 May 2014, at 21:11, Adrian Chadd <adrian.chadd@gmail.com> =
wrote:
>>=20
>>> There's an alignment hack option in the ffmpeg port though. It's not =
a
>>> cflags thing, it's a ./configure thing.
>>>=20
>>>=20
>>>=20
>>>=20
>>> -a
>>>=20
>>>=20
>>> On 9 May 2014 11:40, Dimitry Andric <dim@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.
>>>>=20
>>>> Looking at the build logs, I see
>>>>=20
>>>> 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
>>>> ...
>>>>=20
>>>> The command line flags used for compilation (wrapped for clarity) =
don't seem to include specific ones that change stack alignment =
behavior:
>>>>=20
>>>> cc \
>>>> -I. \
>>>> -I./ \
>>>> -DLIBICONV_PLUG \
>>>> -D_ISOC99_SOURCE \
>>>> -D_FILE_OFFSET_BITS=3D64 \
>>>> -D_LARGEFILE_SOURCE \
>>>> -DHAVE_AV_CONFIG_H \
>>>> -O2 \
>>>> -pipe \
>>>> -march=3Dcorei7 \
>>>> -DLIBICONV_PLUG \
>>>> -fno-strict-aliasing \
>>>> -msse \
>>>> -I/usr/local/include/vorbis \
>>>> -I/usr/local/include \
>>>> -std=3Dc99 \
>>>> -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=3Dimplicit-function-declaration \
>>>> -Werror=3Dmissing-prototypes \
>>>> -Werror=3Dreturn-type \
>>>> -MMD \
>>>> -c \
>>>>=20
>>>> I'll build chromium with the default options, and see what happens.
>>>>=20
>>>> -Dimitry
>>>>=20
>>>> On 09 May 2014, at 19:09, Adrian Chadd <adrian.chadd@gmail.com> =
wrote:
>>>>=20
>>>>> What's the magic to get the normal ffmpeg port to work right?
>>>>>=20
>>>>>=20
>>>>> -a
>>>>>=20
>>>>>=20
>>>>> On 9 May 2014 10:05, Dimitry Andric <dim@freebsd.org> wrote:
>>>>>> On 09 May 2014, at 18:42, Adrian Chadd <adrian.chadd@gmail.com> =
wrote:
>>>>>>> On 9 May 2014 06:50, Pedro Giffuni <pfg@freebsd.org> wrote:
>>>>>>>> Hello;
>>>>>>>>=20
>>>>>>>> El 5/9/2014 5:56 AM, Adrian Chadd escribi=F3:
>>>>>>>>=20
>>>>>>>>> Hi guys,
>>>>>>>>>=20
>>>>>>>>> I filed a PR recently with chromium crashes in its internal =
libffmpeg:
>>>>>>>>>=20
>>>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D189317
>>>>>>>>>=20
>>>>>>>>> What do you two think? It's that Linux 16 byte alignment on =
i386 issue
>>>>>>>>> that has been creeping up every few years.
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Ouch, that's clang, right?
>>>>>>>=20
>>>>>>> I gather so? It's whatever the binary package building cluster =
is
>>>>>>> using. I think it's clang for i386.
>>>>>>=20
>>>>>> For 10.x and 11.x, that should indeed be clang.
>>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>> I recently brought this from OpenBSD, no idea if it's related:
>>>>>>>>=20
>>>>>>>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D265231
>>>>>>>>=20
>>>>>>>> For now I guess we should just patch the libffmpeg port like =
the NetBSD guys
>>>>>>>> did.
>>>>>>>=20
>>>>>>> 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 =
=3D=3D 16
>>>>>>> byte alignment now" switch. I vaguely recall that they made
>>>>>>> _everything_ 16 byte aligned but I can't be sure.
>>>>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D38496
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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...
>>>>>>=20
>>>>>> -Dimitry
>>>>>>=20
>>>>=20
>>=20
--Apple-Mail=_DB0D4E9F-E99E-4144-AB92-39CA05FD7424--
--Apple-Mail=_8352BF35-F254-4160-B3F6-D6A62FB167B5
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlNxRlAACgkQsF6jCi4glqO8fACcCQxLUXC9mP36U1Cve3aYk4Fi
TOEAoJMVQzt/avGoPsYZmWlE3vSMnrJ5
=hpj/
-----END PGP SIGNATURE-----
--Apple-Mail=_8352BF35-F254-4160-B3F6-D6A62FB167B5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9BF4309C-9D56-467F-B882-754B8C94AA29>