From owner-freebsd-chromium@FreeBSD.ORG Mon May 12 22:08:29 2014 Return-Path: Delivered-To: chromium@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D73A946; Mon, 12 May 2014 22:08:29 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8C5C2661; Mon, 12 May 2014 22:08:28 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::dc5b:2c60:28ec:bd2d] (unknown [IPv6:2001:7b8:3a7:0:dc5b:2c60:28ec:bd2d]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 502055C43; Tue, 13 May 2014 00:08:19 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8352BF35-F254-4160-B3F6-D6A62FB167B5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses From: Dimitry Andric In-Reply-To: Date: Tue, 13 May 2014 00:08:09 +0200 Message-Id: <9BF4309C-9D56-467F-B882-754B8C94AA29@FreeBSD.org> References: <536CDD30.40104@FreeBSD.org> <7C272AE1-BA6E-48A9-9662-79B1030D0903@FreeBSD.org> <9810619D-DF65-4A4F-9720-B22DC791EA65@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: chromium@freebsd.org, Pedro Giffuni X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 22:08:29 -0000 --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 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 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 = 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 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 = 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 wrote: >>>>>> On 09 May 2014, at 18:42, Adrian Chadd = wrote: >>>>>>> On 9 May 2014 06:50, Pedro Giffuni 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--