[Bug 224917] www/firefox: bus error on stable/10 with 57.0.3,1

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224917

--- Comment #17 from Dimitry Andric <dim at 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 has
> used two regular mov instructions instead of SSE:
> 
>   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_typeImN7mozilla3ipc14MessageChannel13PromiseHo
> lderEEENS_19__map_value_compareImS6_NS_4lessImEELb1EEENS_9allocatorIS6_EEE7de
> stroyEPNS_11__tree_nodeIS6_PvEE>
>   ceac85:       49 c7 86 18 01 00 00    movq   $0x0,0x118(%r14)
>   ceac8c:       00 00 00 00 
>   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 
>   ceaca2:       49 c7 46 38 00 00 00    movq   $0x0,0x38(%r14)
>   ceaca9:       00 
>   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<> object:

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

    mWorkerLoop = nullptr;
    delete mLink;
    mLink = nullptr;

The [1] line expands to:

        movq    272(%r14), %rsi
        movq    -56(%rbp), %rdi         # 8-byte Reload
        callq  
_ZNSt3__16__treeINS_12__value_typeImN7mozilla3ipc14MessageChannel13PromiseHolderEEENS_19__map_value_compareImS6_NS_4lessImEELb1EEENS_9allocatorIS6_EEE7destroyEPNS_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() = 0;
    __begin_node() = __end_node();
    __end_node()->__left_ = 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=revision&revision=276003

"""
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 fancy
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 version 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 might be
a workaround.

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