From owner-freebsd-chromium@FreeBSD.ORG Fri May 9 21:53:23 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 7FA1BBE; Fri, 9 May 2014 21:53:23 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A8EAA77; Fri, 9 May 2014 21:53:22 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id i17so5229152qcy.22 for ; Fri, 09 May 2014 14:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Yzi2+Nb/iayZAqEsHrSO+zAjvKe5gOXi5OjAFUMTOls=; b=n6A60buM2ekQap+3GbGsrzlcnUtiRn0o9cUvl/ACvWvv7EAUST0vNAnGP/omJmGIPU Le7A/BeODqa8QOgA5O17Ri/gSxXzwwXeOqG4g5Wz5lh4UT/KqCDMH10hfjaMi/40uT8y uwA0bUkDuwJ7yMv7irfAO5ABoYbHyUHUog0H4oKK1/2qrFJivictDpCIDdubQJmPQ6Oz t/ddotVhXDgH6u26DCNLNMjWElzW9qiEKL1jW14Bri8+8lN/d6+YgZQpUvYNHR9+tlQQ NkQP9USwLzIRpHnW32/Nq3qJOS03daXgLZfXWkoFQdPbGxwWPeyNVY9ALbfBJ9QXI9Jv D3tA== MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr18958075qaa.76.1399672402210; Fri, 09 May 2014 14:53:22 -0700 (PDT) Received: by 10.224.191.201 with HTTP; Fri, 9 May 2014 14:53:22 -0700 (PDT) In-Reply-To: References: <536CDD30.40104@FreeBSD.org> <7C272AE1-BA6E-48A9-9662-79B1030D0903@FreeBSD.org> <9810619D-DF65-4A4F-9720-B22DC791EA65@FreeBSD.org> Date: Fri, 9 May 2014 14:53:22 -0700 Message-ID: Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses From: Adrian Chadd To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 09 May 2014 21:53:23 -0000 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 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 w= hile 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 di= splaying a certain website? > > -Dimitry > > On 09 May 2014, at 21:11, Adrian Chadd 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 wrote: >>> I just tried building multimedia/ffmpeg on i386-freebsd11, with the def= ault 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=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 \ >>> >>> I'll build chromium with the default options, and see what happens. >>> >>> -Dimitry >>> >>> On 09 May 2014, at 19:09, Adrian Chadd wrote: >>> >>>> What's the magic to get the normal ffmpeg port to work right? >>>> >>>> >>>> -a >>>> >>>> >>>> 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; >>>>>>> >>>>>>> El 5/9/2014 5:56 AM, Adrian Chadd escribi=C3=B3: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> I filed a PR recently with chromium crashes in its internal libffm= peg: >>>>>>>> >>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D189317 >>>>>>>> >>>>>>>> What do you two think? It's that Linux 16 byte alignment on i386 i= ssue >>>>>>>> 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=3Drevision&revision=3D265231 >>>>>>> >>>>>>> For now I guess we should just patch the libffmpeg port like the Ne= tBSD guys >>>>>>> did. >>>>>> >>>>>> Kind of? The x86-64 ABI requires 16 byte alignment for a lot of stuf= f. >>>>>> 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. >>>>> >>>>> 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=3D38496 >>>>> >>>>> 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 rando= m >>>>> stack-allocated variable. Obviously, on i386-freebsd, that is not th= e >>>>> case, as we still maintain the old SysV 4-byte alignment. >>>>> >>>>> FFmpeg is one of those projects that assumes 16-byte alignment, and a= lso >>>>> has a lot of hand-written SSE assembly, either inline or in separate >>>>> yasm sources. The brute-force way of fixing trouble with alignment i= s >>>>> to add -mstackrealign to CFLAGS, but I'm not sure if that is the corr= ect >>>>> 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 vers= ion >>>>> of FFmpeg in a similar manner as the regular FFmpeg port? I'm not su= re >>>>> I will have enough time to have look at it soon, though... >>>>> >>>>> -Dimitry >>>>> >>> >