Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 10 Jan 2018 21:08:58 +0000
From:      bugzilla-noreply@freebsd.org
To:        gecko@FreeBSD.org
Subject:   [Bug 224917] www/firefox: bus error on stable/10 with 57.0.3,1
Message-ID:  <bug-224917-21738-qDN237tbQm@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-224917-21738@https.bugs.freebsd.org/bugzilla/>
References:  <bug-224917-21738@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224917

--- Comment #17 from Dimitry Andric <dim@FreeBSD.org> ---
(In reply to Jilles Tjoelker from comment #2)
> I rebuilt firefox-57.0.3,1 from a (slightly more recent) ports tree with =
SVN
> r457360 reverted. This seems to run stably for 20 minutes and the
> disassembly of the corresponding part of libxul.so shows that clang 4.0 h=
as
> used two regular mov instructions instead of SSE:
>=20
>   ceac73:       75 9b                   jne    ceac10
> <_ZN7mozilla3ipc14MessageChannel5ClearEv+0x90>
>   ceac75:       49 8b b6 10 01 00 00    mov    0x110(%r14),%rsi
>   ceac7c:       48 8b 7d c8             mov    -0x38(%rbp),%rdi
>   ceac80:       e8 9b bf 00 00          callq  cf6c20
> <_ZNSt3__16__treeINS_12__value_typeImN7mozilla3ipc14MessageChannel13Promi=
seHo
> lderEEENS_19__map_value_compareImS6_NS_4lessImEELb1EEENS_9allocatorIS6_EE=
E7de
> stroyEPNS_11__tree_nodeIS6_PvEE>
>   ceac85:       49 c7 86 18 01 00 00    movq   $0x0,0x118(%r14)
>   ceac8c:       00 00 00 00=20
>   ceac90:       4d 89 be 08 01 00 00    mov    %r15,0x108(%r14)
>   ceac97:       49 c7 86 10 01 00 00    movq   $0x0,0x110(%r14)
>   ceac9e:       00 00 00 00=20
>   ceaca2:       49 c7 46 38 00 00 00    movq   $0x0,0x38(%r14)
>   ceaca9:       00=20
>   ceacaa:       49 8b 7e 30             mov    0x30(%r14),%rdi
>   ceacae:       48 85 ff                test   %rdi,%rdi
>   ceacb1:       74 06                   je     ceacb9
> <_ZN7mozilla3ipc14MessageChannel5ClearEv+0x139>

The code in question is, strangely, just the clearing of a std::map<> objec=
t:

void
MessageChannel::Clear()
{
[...]
   gUnresolvedPromises -=3D mPendingPromises.size();
    for (auto& pair : mPendingPromises) {
        pair.second.mRejectFunction(pair.second.mPromise,
                                    PromiseRejectReason::ChannelClosed,
                                    __func__);
    }
    mPendingPromises.clear();  /// <--- [1]

    mWorkerLoop =3D nullptr;
    delete mLink;
    mLink =3D nullptr;

The [1] line expands to:

        movq    272(%r14), %rsi
        movq    -56(%rbp), %rdi         # 8-byte Reload
        callq=20=20
_ZNSt3__16__treeINS_12__value_typeImN7mozilla3ipc14MessageChannel13PromiseH=
olderEEENS_19__map_value_compareImS6_NS_4lessImEELb1EEENS_9allocatorIS6_EEE=
7destroyEPNS_11__tree_nodeIS6_PvEE
        movq    %r15, 264(%r14)
        xorps   %xmm0, %xmm0
        movaps  %xmm0, 272(%r14)

Here, the mangled function is just an internal destroy function of std::map,
and the instructions just after that are the last 3 lines of __tree::clear =
(in
/usr/include/c++/v1/__tree):

template <class _Tp, class _Compare, class _Allocator>
void
__tree<_Tp, _Compare, _Allocator>::clear() _NOEXCEPT
{
    destroy(__root());
    size() =3D 0;
    __begin_node() =3D __end_node();
    __end_node()->__left_ =3D nullptr;
}

Strangely, it turned out that rebuilding MessageChannel.cpp with newer libc=
++
headers made the movaps instruction change to movups, even with clang 5.0.0=
.  I
bisected through the libc++ history, and ended up at this commit:

http://llvm.org/viewvc/llvm-project?view=3Drevision&revision=3D276003

"""
Fix undefined behavior in __tree

Summary:
This patch attempts to fix the undefined behavior in __tree by changing the
node pointer types used throughout. The pointer types are changed for raw
pointers in the current ABI and for fancy pointers in ABI V2 (since the fan=
cy
pointer types may not be ABI compatible).

The UB in `__tree` arises because tree downcasts the embedded end node and =
then
deferences that pointer. Currently there are 3 node types in __tree.
[... read original message for full story...]
"""

Unfortunately this fix is rather extensive, and hard to apply to the versio=
n of
libc++ in stable/10, which is still approximately at version 3.4.1.

I will have a look at backporting the fix.  Meanwhile, maybe lowering the
optimization level for this particular file, or just using clang 4.0.x migh=
t be
a workaround.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224917-21738-qDN237tbQm>