Date: Tue, 30 Apr 2013 11:34:34 -0500 From: Jan Beich <jbeich@tormail.org> To: Brandon Gooch <jamesbrandongooch@gmail.com> Cc: kit <ktsin@acm.org>, Dimitry Andric <dim@freebsd.org>, freebsd-ports@freebsd.org Subject: Re: firefox build broken under clang 3.3 Message-ID: <1UXDVA-0001b7-7U@internal.tormail.org> In-Reply-To: <CALBk6yLOV8fzdAY9y0_7SZvR9N8J-19FrwZjFv4t14ub8wmGiA@mail.gmail.com> (Brandon Gooch's message of "Mon, 29 Apr 2013 22:28:56 -0500") References: <20130419020021.GA16918@test.yahoo.com> <51716917.90101@smeets.im> <F82EAEBA-C47D-4AC6-8FAE-AC3541B131C7@FreeBSD.org> <517187B9.40106@smeets.im> <CALBk6yLOV8fzdAY9y0_7SZvR9N8J-19FrwZjFv4t14ub8wmGiA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Brandon Gooch <jamesbrandongooch@gmail.com> writes: > On Fri, Apr 19, 2013 at 1:06 PM, Florian Smeets <flo@smeets.im> wrote: >> On 19.04.13 19:48, Dimitry Andric wrote: >>> On Apr 19, 2013, at 17:56, Florian Smeets <flo@smeets.im> wrote: >>> >>>> On 19.04.13 04:01, kit wrote: >>>>> updated current and now firefox and thunderbird both fail to build under >>>>> the new clang 3.3. has anyone seen this or know how to fix? >>>> >>>> The fix is here: >>>> >>>> http://tb.smeets.im/~flo/gecko-clang33-fixes.diff >>>> >>>> It will be committed after the freeze. >>> >>> Are these fixes from upstream? If not, it would be nice to send them there... >>> >>> >> >> patch-bug854936 is a workaround because we don't have >> http://llvm.org/viewvc/llvm-project?view=revision&revision=178950 yet. >> >> firefox-nightly (in our gecko svn repo) already compiles fine without >> patch-clang33 >> >> So everything should be fine :) >> >> Florian > > Thanks for fixing the build issues. > > Now, I've built Firefox with Clang, but the darn thing segfaults at > the drop of a hat: > > $ gdb /usr/local/bin/firefox firefox.core > ... > (gdb) bt > #0 0x00000008011eefaa in thr_kill () from /lib/libc.so.7 > #1 0x00000008024d254d in XRE_InstallX11ErrorHandler () > from /usr/local/lib/firefox/libxul.so > #2 0x0000000800f74116 in swapcontext () from /lib/libthr.so.3 > #3 0x0000000800f73d39 in sigaction () from /lib/libthr.so.3 > #4 0x00007ffffffff193 in ?? () > #5 0x0000000800f73c20 in sigaction () from /lib/libthr.so.3 > Previous frame inner to this frame (corrupt stack?) The faulting function is lost within crash handler. If you build firefox with # use DEBUG_FLAGS or set STRIP to empty explicitly CFLAGS += ${DEBUG_FLAGS} DEBUG_FLAGS += -O0 -g jaeger jit crash would look like http://lists.freebsd.org/pipermail/freebsd-current/2013-April/041165.html It doesn't happen on firefox23 with baseline jit[1] disabled via pref. A big change like zones (bug 759585) may have refactored code enough to not hit the clang bug. So, try either clang trunk or http://trillian.chruetertee.ch/freebsd-gecko/changeset/1256/trunk/www/firefox/files/patch-clang33 The latter pessimizes inlining for clang 3.2 as well. [1] baseline crashes in a different way https://bugzilla.mozilla.org/show_bug.cgi?id=860867 > > Rebuilding with debugging symbols provides no further insight, as that > seems to provide a work-around for whatever the root cause may be > (i.e. no more segfaults). DEBUG enables compile-time diagnostics and strips any -O* from CFLAGS.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1UXDVA-0001b7-7U>