From owner-freebsd-chromium@FreeBSD.ORG Mon May 26 14:03:46 2014 Return-Path: Delivered-To: chromium@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ADEFA1A; Mon, 26 May 2014 14:03:46 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 821C726A4; Mon, 26 May 2014 14:03:45 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so108130wib.2 for ; Mon, 26 May 2014 07:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2ZnEXD3J+F8LhIGOyttYPeus+Fzzr3PYdx+goeouAQM=; b=Quu7FBih8J6PW4lcMBl+y6ficU/JMEDZDgh3v9AsYsAp2tXfqAlbLsGiJzEoA/K3+D qI5Djmxcq2vAh9NNWSjuWpweMqZQC7IhuCwRCjMGC9RtSomUvhyG/kgaQRAd8nfGQwqT 39SG9w+Itn+RA9v/vkZ+4fx8QqCI5VlhsixRveXCiMpW1v0wx5ZWJPnKCxXHEvRGtSt6 4uc/5Ij55X5uj1tQe4ovlOEb99Ew2BUyHDwgYYvdoixA7x1Thzo8CtO1JSkWwabT2kBH Cz3T8mtVzH7RDOSgW/+Do36cerLXLkcJDTdGdpdrm5JiP/MKlu2rc13RiMXCKeq76foz 8IVg== X-Received: by 10.194.8.200 with SMTP id t8mr22989575wja.19.1401113022604; Mon, 26 May 2014 07:03:42 -0700 (PDT) Received: from [192.168.178.20] (a82-161-212-209.adsl.xs4all.nl. [82.161.212.209]) by mx.google.com with ESMTPSA id g10sm27120308wjs.33.2014.05.26.07.03.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 07:03:41 -0700 (PDT) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <538349BB.8050300@freebsd.org> Date: Mon, 26 May 2014 16:03:39 +0200 From: =?UTF-8?B?UmVuw6kgTGFkYW4=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Adrian Chadd , Dimitry Andric Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses 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> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 26 May 2014 14:03:46 -0000 Hi, you mean that the patch I made out of Dimitrys patch works fine? René On 05/20/2014 18:28, Adrian Chadd wrote: > 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/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=16 >> -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 >> >> >> 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 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 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 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. >>>>>> >>>>>> 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=64 \ >>>>>> -D_LARGEFILE_SOURCE \ >>>>>> -DHAVE_AV_CONFIG_H \ >>>>>> -O2 \ >>>>>> -pipe \ >>>>>> -march=corei7 \ >>>>>> -DLIBICONV_PLUG \ >>>>>> -fno-strict-aliasing \ >>>>>> -msse \ >>>>>> -I/usr/local/include/vorbis \ >>>>>> -I/usr/local/include \ >>>>>> -std=c99 \ >>>>>> -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=implicit-function-declaration \ >>>>>> -Werror=missing-prototypes \ >>>>>> -Werror=return-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ó: >>>>>>>>>> >>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>> I filed a PR recently with chromium crashes in its internal libffmpeg: >>>>>>>>>>> >>>>>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=189317 >>>>>>>>>>> >>>>>>>>>>> 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=revision&revision=265231 >>>>>>>>>> >>>>>>>>>> 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 stuff. >>>>>>>>> The i386 32 bit ABI doesn't require 16 byte alignment as per >>>>>>>>> everything pre-Linux-in-2005ish. Linux / gcc flipped the "i386 == 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=38496 >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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... >>>>>>>> >>>>>>>> -Dimitry >>>>>>>> >>>>>> >>>> >> >> > _______________________________________________ > freebsd-chromium@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-chromium > To unsubscribe, send any mail to "freebsd-chromium-unsubscribe@freebsd.org" >