Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: firefox build broken under clang 3.3

3 views
Skip to first unread message

Brandon Gooch

unread,
Apr 29, 2013, 11:28:56 PM4/29/13
to
On Fri, Apr 19, 2013 at 1:06 PM, Florian Smeets <f...@smeets.im> wrote:
> On 19.04.13 19:48, Dimitry Andric wrote:
>> On Apr 19, 2013, at 17:56, Florian Smeets <f...@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?)

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).

Are any of you seeing something similar?

-Brandon
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"

Dimitry Andric

unread,
Apr 30, 2013, 11:25:22 AM4/30/13
to
On Apr 30, 2013, at 05:28, Brandon Gooch <jamesbra...@gmail.com> wrote:
...
> 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?)
>
> 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).
>
> Are any of you seeing something similar?

Which exact version of head do you have, and which version(s) of ports? Are you running WITH_NEW_XORG or not?

In any case, I have just built the latest Firefox from ports, with clang 3.3, and I see no issues at all. At least with approximately 10 minutes of browsing, and visiting a varied bunch of sites. I do have it built with debug info, but without cranking down the optimization level to -O0 (which is what bsd.port.mk seems to do, unfortunately).

I will rebuild it again, without any debug info, to see if that makes any difference. I don't think it will, though...

Jan Beich

unread,
Apr 30, 2013, 12:34:34 PM4/30/13
to
Brandon Gooch <jamesbra...@gmail.com> writes:

> On Fri, Apr 19, 2013 at 1:06 PM, Florian Smeets <f...@smeets.im> wrote:
>> On 19.04.13 19:48, Dimitry Andric wrote:
>>> On Apr 19, 2013, at 17:56, Florian Smeets <f...@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.

Dimitry Andric

unread,
Apr 30, 2013, 2:07:57 PM4/30/13
to
On Apr 30, 2013, at 17:25, Dimitry Andric <d...@freebsd.org> wrote:
...
> In any case, I have just built the latest Firefox from ports, with clang 3.3, and I see no issues at all. At least with approximately 10 minutes of browsing, and visiting a varied bunch of sites. I do have it built with debug info, but without cranking down the optimization level to -O0 (which is what bsd.port.mk seems to do, unfortunately).
>
> I will rebuild it again, without any debug info, to see if that makes any difference. I don't think it will, though...

Rebuilt without debug info, worked just fine. Is there a particular scenario that makes it crash?

Dimitry Andric

unread,
Apr 30, 2013, 2:23:34 PM4/30/13
to
On Apr 30, 2013, at 18:34, Jan Beich <jbe...@tormail.org> wrote:
...
> 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

The firefox crash in that post was with -O2, so it is most likely not due to the vectorizer then.

In any case, I have not been able to reproduce that either. I have browsed stackoverflow.com for about 5 minutes, clicking a whole bunch of random articles and links, and no problems whatsoever occurred. That is with the default www/firefox port, which seems to be the released Firefox 20.0, at its default settings, on amd64.


> 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

I do not like the workaround in that Mozilla bug, since it simply disables the vectorizer. I can understand that software must always ship tomorrow, but it would have been nicer to attempt to figure out what is incorrectly optimized, and why...


>> 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.

Indeed. To work around this, use the following diff:

Index: Mk/bsd.port.mk
===================================================================
--- Mk/bsd.port.mk (revision 316903)
+++ Mk/bsd.port.mk (working copy)
@@ -1580,7 +1580,7 @@
.if defined(WITH_DEBUG) && !defined(WITHOUT_DEBUG)
STRIP_CMD= ${TRUE}
DEBUG_FLAGS?= -g
-CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
.endif

.if defined(NOPORTDOCS)

Rafael Espíndola

unread,
Apr 30, 2013, 10:55:54 PM4/30/13
to
OK, I was able to reproduce this. I am trying to reduce the testcase.

Rafael Espíndola

unread,
May 1, 2013, 12:26:21 AM5/1/13
to
This is now

http://llvm.org/bugs/show_bug.cgi?id=15882

Someone familiar with the baseline compiler might be able to spot what
is wrong with the optimization.

Cheers,
Rafael

Brandon Gooch

unread,
May 5, 2013, 9:07:13 AM5/5/13
to
On Tue, Apr 30, 2013 at 11:26 PM, Rafael Espíndola
<rafael.e...@gmail.com> wrote:
> This is now
>
> http://llvm.org/bugs/show_bug.cgi?id=15882
>
> Someone familiar with the baseline compiler might be able to spot what
> is wrong with the optimization.
>
> Cheers,
> Rafael

Just an FYI, I've been using firefox-21.0.b3,1 from:

$ svn info
Path: .
Working Copy Root Path: /usr/home/brandon/wc/freebsd-gecko
URL: https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk/www/firefox
Repository Root: https://trillian.chruetertee.ch/svn/freebsd-gecko
Repository UUID: 6ab5617d-af29-de11-a9e3-001676731981
Revision: 1258
Node Kind: directory
Schedule: normal
Last Changed Author: jbeich
Last Changed Rev: 1256
Last Changed Date: 2013-04-30 04:35:07 -0500 (Tue, 30 Apr 2013)

I've not have a crash since.

-Brandon

Rafael Espíndola

unread,
May 7, 2013, 8:59:53 AM5/7/13
to
On 1 May 2013 00:26, Rafael Espíndola <rafael.e...@gmail.com> wrote:
> This is now
>
> http://llvm.org/bugs/show_bug.cgi?id=15882

And it got fixed! :-)

It just missed 3.3 branching, but I will make sure it gets ported.

Cheers,
Rafael

Dimitry Andric

unread,
May 7, 2013, 10:45:30 AM5/7/13
to
On 2013-05-07 14:59, Rafael Espíndola wrote:
> On 1 May 2013 00:26, Rafael Espíndola <rafael.e...@gmail.com> wrote:
>> This is now
>>
>> http://llvm.org/bugs/show_bug.cgi?id=15882
>
> And it got fixed! :-)
>
> It just missed 3.3 branching, but I will make sure it gets ported.

Okay, can the original posters that suffered from the crash, please try
the attached patch on their -current source, then try to rebuild the
Firefox port, and check if the crash has disappeared?

If you just want to incrementally build clang, you can do:

cd /usr/src/lib/clang/libllvmvectorize
make
cd /usr/src/usr.bin/clang/clang
make
sudo make install

-Dimitry
fix-llvm-pr15882-1.diff
0 new messages