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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>>> What's the magic to get the normal ffmpeg port to work right? >>>>>>> >>>>>>> >>>>>>> -a >>>>>>> >>>>>>> >>>>>>> On 9 May 2014 10:05, Dimitry Andric <[email protected]> wrote: >>>>>>>> On 09 May 2014, at 18:42, Adrian Chadd <[email protected]> wrote: >>>>>>>>> On 9 May 2014 06:50, Pedro Giffuni <[email protected]> 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 >>>>>>>> >>>>>> >>>> >> >> > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-chromium > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-chromium To unsubscribe, send any mail to "[email protected]"
