From owner-freebsd-chromium@FreeBSD.ORG Tue May 20 16:28: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 276668CE; Tue, 20 May 2014 16:28:23 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 A4FD926CC; Tue, 20 May 2014 16:28:22 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id i50so1117003qgf.17 for ; Tue, 20 May 2014 09:28:21 -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=FcizPZAPoY8Z4jhvHWHPBUqr/0ipX2Zxp3P0+G7ym7E=; b=SznYvKnzZ4nca1soGUDWSTrTJ2AKDwwoR9QwPAeuS2rDpkjvbS5cQ/fJPRQTgxEsJZ SrWKuOkNsyAOAfDPcp/a3xZznuu84pMZeq1TaalhnGAJGEEMoWCdklvUx91A49+O/KUh Jjbi1gP+YlEUstEI6S9zZHp+iattbCf63x3i01Cvvn7y/npKrS3w5Y2QnIrC9cxab3mm H+0XWW6eevNiogIrEDMWA+KSeCBbxaU6JIyiUGJL1MUJSjYKpE4AaIMuuwNHDX43sc0y zgmUSuunwatJJ7f1EL6lE6uu0gXzgZtYThlAeff/IktZBkwk99j1Hrmaxamy9broAlB4 vvmw== MIME-Version: 1.0 X-Received: by 10.140.104.195 with SMTP id a61mr57603886qgf.102.1400603301825; Tue, 20 May 2014 09:28:21 -0700 (PDT) Received: by 10.224.191.201 with HTTP; Tue, 20 May 2014 09:28:21 -0700 (PDT) In-Reply-To: <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> <9BF4309C-9D56-467F-B882-754B8C94AA29@FreeBSD.org> Date: Tue, 20 May 2014 09:28:21 -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: Tue, 20 May 2014 16:28:23 -0000 Hi, So whose arm should I twist to get this stuff committed to both the libffmpeg and chromium ports? -a On 12 May 2014 15:08, Dimitry Andric wrote: > Since I still can't reproduce any crashes with the current multimedia/ffm= peg 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 seem= s to use yet another NIH build system of the month. This is probably somet= hing for the chromium maintainers to figure out. > > The basic idea is to to add the following flags, if building with clang o= n i386-freebsd (ffmpeg confusingly calls this x86_32, which is something to= tally 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 b= roken there anyway... > > -Dimitry > > > 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. >> >> 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 t= o 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 eithe= r. It must be because I'm running a VMware guest, and chromium does not co= pe with that too well (Firefox seems to work much better, though not terrib= ly 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 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 d= efault 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 wro= te: >>>>>>>> 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 libf= fmpeg: >>>>>>>>>> >>>>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D189317 >>>>>>>>>> >>>>>>>>>> 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=3Drevision&revision=3D265231 >>>>>>>>> >>>>>>>>> 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 st= uff. >>>>>>>> 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 200= 8, >>>>>>> without any consideration for backwards compatibility, and this lea= d 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 simpl= y >>>>>>> assume everything on x86 has 16-byte aligned stacks, and you can us= e SSE >>>>>>> instructions that require strict alignment (e.g. movaps) on any ran= dom >>>>>>> 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 separat= e >>>>>>> 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 co= rrect >>>>>>> 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 ve= rsion >>>>>>> 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 >>>>>>> >>>>> >>> > >