Date: Fri, 9 May 2014 23:49:11 +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: <FC7C93ED-F20B-4999-BF84-280F9DA9926A@FreeBSD.org> In-Reply-To: <CAJ-VmoknOe8d9H5o8D1XMWn%2Bq%2B_aJ-B46URwkOsnVkWAXEhamw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_E6738806-3E93-48AA-B6A9-47E96A8469E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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@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. >=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 --Apple-Mail=_E6738806-3E93-48AA-B6A9-47E96A8469E6 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) iEYEARECAAYFAlNtTWAACgkQsF6jCi4glqNDtACfapbhi/IH62nkJWHQhxebX84x Fn0AoIpbUfsrDmYgk8PzE1ndkn/yLpTu =HOTG -----END PGP SIGNATURE----- --Apple-Mail=_E6738806-3E93-48AA-B6A9-47E96A8469E6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FC7C93ED-F20B-4999-BF84-280F9DA9926A>