[cfe-dev] [libc++] r160604 appears to have broken libc++ on linux

[Howard Hinnant]

On Jul 22, 2012, at 7:12 PM, "Andrew C. Morrow" <andrew.c.morrow at gmail.com> wrote:

> I have a mostly working clang toolchain on Linux using libc++abi and
> libc++. But today I pulled the latest updates to libc++ and rebuilt
> it, and now any attempt to construct a std::stringstream fails.
> 
> #include <sstream>
> 
> int main(int argc, char* argv[]) {
>    std::stringstream ss;
>    return EXIT_SUCCESS;
> }
> 
> This dies with an unhandled std::bad_cast exception:
> 
> terminating with uncaught exception of type std::bad_cast: std::bad_cast
> 
> Program received signal SIGABRT, Aborted.
> 0x00007ffff75f0475 in *__GI_raise (sig=<optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) where
> #0  0x00007ffff75f0475 in *__GI_raise (sig=<optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x00007ffff75f36f0 in *__GI_abort () at abort.c:92
> #2  0x00007ffff7fcd457 in abort_message (format=<optimized out>) at
> ../../../src/libcxxabi/src/abort_message.cpp:47
> #3  0x00007ffff7fcd6c2 in default_handler (cause=0x7ffff7fe3ba3
> "uncaught") at ../../../src/libcxxabi/src/cxa_default_handlers.cpp:61
> #4  0x00007ffff7fcd54d in default_terminate_handler () at
> ../../../src/libcxxabi/src/cxa_default_handlers.cpp:81
> #5  0x00007ffff7fe0676 in std::__terminate (func=0xeed9) at
> ../../../src/libcxxabi/src/cxa_handlers.cpp:67
> #6  0x00007ffff7fdfce6 in failed_throw (exception_header=<optimized
> out>) at ../../../src/libcxxabi/src/cxa_exception.cpp:147
> #7  __cxa_throw (thrown_object=0x406090, tinfo=<optimized out>,
> dest=<optimized out>) at
> ../../../src/libcxxabi/src/cxa_exception.cpp:242
> #8  0x00007ffff7e8f857 in std::__1::locale::__imp::use_facet
> (this=0x7ffff7faba70, id=28) at
> /home/acm/Documents/Develop/externals/clang-toolchain/src/libcxx/src/locale.cpp:388
> #9  0x00007ffff7e90633 in std::__1::locale::use_facet
> (this=0x7fffffffe540, x=...) at
> /home/acm/Documents/Develop/externals/clang-toolchain/src/libcxx/src/locale.cpp:530
> #10 0x0000000000401e8a in init (this=0x7fffffffe310,
> __sb=0x7fffffffe2a8) at /home/acm/opt/include/c++/v1/ios:660
> #11 basic_istream (this=0x0, vtt=0x7fffffffe660, __sb=0x7fffffffe2a8,
> this=0x0, vtt=0x7fffffffe660) at
> /home/acm/opt/include/c++/v1/istream:294
> #12 basic_ios (this=0x7ffff7e109c0, this=0x7ffff7e109c0, vtt=0x404788,
> __sb=0x7fffffffe2a8, this=0x7ffff7e109c0, __wch=32767) at
> /home/acm/opt/include/c++/v1/istream:1488
> #13 basic_stringstream (this=0x7fffffffe290, __wch=24) at
> /home/acm/opt/include/c++/v1/sstream:809
> #14 main (argc=1, argv=0x7fffffffe668) at ./test.cpp:26
> (gdb)
> 
> In addition to my trivial test case, many of the libc++abi and libc++
> unit tests fail with similar exceptions when r160604 is applied.
> 
> If I revert libc++ back to r160594 things start working again.
> 
> The rest of toolchain was built with the following component revisions:
> llvm: r160611
> clang: r160613
> libc++abi: r160553
> 
> It is not immediately obvious to me how r160604's noexcept and
> constexpr changes to std::mutex could cause this. Valgrind didn't have
> anything interesting to say. Any suggestions about where to start
> looking?

It isn't obvious to me either.

In locale.cpp, this throw is happening:

const locale::facet*
locale::__imp::use_facet(long id) const
{
#ifndef _LIBCPP_NO_EXCEPTIONS
    if (!has_facet(id))
        throw bad_cast();
#endif  // _LIBCPP_NO_EXCEPTIONS
    return facets_[static_cast<size_t>(id)];
}

But I have no idea why you would be throwing now, and not without the noexcept declarations on mutex et al. in r160594.  I'm not replicating this on Mac OS X.

Here's has_facet:

    bool has_facet(long id) const
        {return static_cast<size_t>(id) < facets_.size() && facets_[static_cast<size_t>(id)];}

which is just range checking the vector of facet pointers which should be constructed by now.

This looks to be happening while default constructing a locale.  But default constructing a locale should not be calling use_facet or has_facet.  This stack trace should be diving into make_global and make_classic in locale.cpp, which call this constructor:

locale::__imp::__imp(size_t refs)

which does not lead to use_facet or has_facet.

So it looks like some kind of corruption going on somewhere.

Howard