Date: Sun, 22 Jun 2014 00:21:54 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Rene Ladan <rene@freebsd.org> Cc: chromium@freebsd.org, Pedro Giffuni <pfg@freebsd.org>, Dimitry Andric <dim@freebsd.org> Subject: Re: libffmpeg chromium crashes due to unaligned SSE accesses Message-ID: <CAJ-Vmomxa9%2Bq0mi93bD3TTSxikNZvWVDeB3oyuSqqm5uhYDg%2BA@mail.gmail.com> In-Reply-To: <CAJ-Vmo=qV419fukjmFHb3p23YcTiXSya9EVWEUpyvPoUjK0T0w@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> <538349BB.8050300@freebsd.org> <CAJ-Vmo=qV419fukjmFHb3p23YcTiXSya9EVWEUpyvPoUjK0T0w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I finally tested this and I haven't seen any crashes so far. Thanks! Would you mind committing it? -a On 26 May 2014 13:48, Adrian Chadd <adrian.chadd@gmail.com> wrote: > I'll double check soon. > > Please realize that a lot of these laptops I have aren't built for doing > large scale package building. I don't have anything with lots of ram and > disks. I run almost exclusively binary packages now days. > > Adrian > > On May 26, 2014 7:03 AM, "Ren=C3=A9 Ladan" <rene@freebsd.org> wrote: >> >> Hi, >> >> you mean that the patch I made out of Dimitrys patch works fine? >> >> Ren=C3=A9 >> >> 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 thin= k >> >> 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 m= onth. >> >> This is probably something for the chromium maintainers to figure out= . >> >> >> >> The basic idea is to to add the following flags, if building with cla= ng >> >> on i386-freebsd (ffmpeg confusingly calls this x86_32, which is somet= hing >> >> 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 po= int of >> >> each function. Something similar is probably needed for gcc, but ali= gnment >> >> 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 combin= ed >> >>> 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 pass= ed >> >>>> 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 chromiu= m does >> >>>> not cope with that too well (Firefox seems to work much better, tho= ugh 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 n= ot >> >>>>> 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 t= he >> >>>>>> default port settings, and it seems to work just fine. I tried t= ranscoding >> >>>>>> a few files, and there were no stack alignment problems or SIGBUS= es. >> >>>>>> >> >>>>>> 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 b= ehavior: >> >>>>>> >> >>>>>> 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 happen= s. >> >>>>>> >> >>>>>> -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=C3=B3: >> >>>>>>>>>> >> >>>>>>>>>>> Hi guys, >> >>>>>>>>>>> >> >>>>>>>>>>> I filed a PR recently with chromium crashes in its internal >> >>>>>>>>>>> libffmpeg: >> >>>>>>>>>>> >> >>>>>>>>>>> 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=3D265= 231 >> >>>>>>>>>> >> >>>>>>>>>> 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 o= f >> >>>>>>>>> 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. >> >>>>>>>> >> >>>>>>>> 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 ca= n >> >>>>>>>> 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 th= e >> >>>>>>>> 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 Chromiu= m >> >>>>>>>> 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?CAJ-Vmomxa9%2Bq0mi93bD3TTSxikNZvWVDeB3oyuSqqm5uhYDg%2BA>