Date: Mon, 26 May 2014 16:03:39 +0200 From: =?UTF-8?B?UmVuw6kgTGFkYW4=?= <rene@freebsd.org> To: Adrian Chadd <adrian.chadd@gmail.com>, Dimitry Andric <dim@freebsd.org> Cc: chromium@freebsd.org, Pedro Giffuni <pfg@freebsd.org> Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses Message-ID: <538349BB.8050300@freebsd.org> In-Reply-To: <CAJ-Vmon5wvaafw7sAzdPK7qmkVPfbi8NA83CBT=YOqAnnF-wVA@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> <FC7C93ED-F20B-4999-BF84-280F9DA9926A@FreeBSD.org> <CAJ-Vmok9o5XLmybGrrjTpGpUAydRNMDek7WkjRbd7EJFXt2-Kg@mail.gmail.com> <9BF4309C-9D56-467F-B882-754B8C94AA29@FreeBSD.org> <CAJ-Vmon5wvaafw7sAzdPK7qmkVPfbi8NA83CBT=YOqAnnF-wVA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dim@freebsd.org> 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 <adrian.chadd@gmail.com> 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 <dim@freebsd.org> 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 <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. >>>>> >>>>> >>>>> >>>>> >>>>> -a >>>>> >>>>> >>>>> 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. >>>>>> >>>>>> 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 <adrian.chadd@gmail.com> wrote: >>>>>> >>>>>>> What's the magic to get the normal ffmpeg port to work right? >>>>>>> >>>>>>> >>>>>>> -a >>>>>>> >>>>>>> >>>>>>> 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; >>>>>>>>>> >>>>>>>>>> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?538349BB.8050300>