[cfe-dev] libc++ and libc++abi problem with stdexcept on linux

[Howard Hinnant]

It looks like the __libcpp_nmstr from libcxxabi/src/stdexcept.cpp needs to be copied/substituted in to the libcxx/src/stdexcept.cpp.  I haven't had a chance to confirm that with full test suite runs.

Howard

On Jan 10, 2014, at 8:03 AM, Alexander Potapenko <glider at google.com> wrote:

> A friendly ping
> 
> On Mon, Dec 30, 2013 at 1:13 PM, Alexander Potapenko <glider at google.com> wrote:
>> ASan complains about the memory being allocated with operator new[]
>> for array types (this is probably done in
>> libcxxabi/src/stdexcept.cpp:78:
>> 
>> 75 __libcpp_nmstr::__libcpp_nmstr(const char* msg)
>> 76 {
>> 77     std::size_t len = strlen(msg);
>> 78     str_ = static_cast<const char*>(::operator new(len + 1 + offset));
>> 
>> ) and deallocated with operator delete for non-array types (at
>> libcxxabi/src/stdexcept.cpp:123:
>> 
>> 116 __libcpp_nmstr::~__libcpp_nmstr()
>> 117 {
>> 118 #if __APPLE__
>> 119     if (str_ != get_gcc_empty_string_storage())
>> 120 #endif
>> 121         if (__sync_add_and_fetch(&count(), count_t(-1)) < 0)
>> 122         {
>> 123             ::operator delete(const_cast<char*>(str_ - offset));
>> 124         }
>> 
>> )
>> 
>> Such a mismatch is explicitly considered UB in the C++11 Standard.
>> 
>> Howard, can you please take a look?
>> 
>> On Mon, Dec 30, 2013 at 9:21 AM, Ben Pope <benpope81 at gmail.com> wrote:
>>> Hi,
>>> 
>>> I've got libc++ linked with libc++abi, but I'm having a problem within
>>> stdexcept, it seems to be mixing up the __libcpp_nmstr from libc++ with
>>> that from libc++abi.
>>> 
>>> I built trunk libc++ and libc++abi on Ubuntu 13.10 with:
>>> CC=clang-3.4 CXX=clang++-3.4 cmake -G "Unix Makefiles"
>>> -DLIBCXX_CXX_ABI=libcxxabi
>>> -DLIBCXX_LIBCXXABI_INCLUDE_PATHS="../../libcxxabi/include"
>>> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr ../
>>> 
>>> 
>>> The following code reproduces this:
>>> 
>>> #include <stdexcept>
>>> 
>>> int main()
>>> {
>>>   try { throw std::runtime_error("Foo"); }
>>>   catch (std::exception const&) {}
>>> }
>>> 
>>> clang++-3.4 -fsanitize=address -std=c++11 -stdlib=libc++ -lc++abi
>>> teststdexcept.cpp -o teststdexcept
>>> 
>>> And the output of ASan:
>>> 
>>> =================================================================
>>> ==12336==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new
>>> [] vs operator delete) on 0x60300000efe0
>>>    #0 0x466019 in operator delete(void*)
>>> /home/ben/development/llvm/3.4/final/llvm.src/projects/compiler-rt/lib/asan/asan_new_delete.cc:83
>>>    #1 0x7f6cbbbca550 in ~__libcpp_nmstr
>>> /home/ben/development/llvm/trunk/libcxxabi/lib/../src/stdexcept.cpp:123
>>>    #2 0x7f6cbbbca550 in std::overflow_error::~overflow_error()
>>> /home/ben/development/llvm/trunk/libcxxabi/lib/../src/stdexcept.cpp:150
>>>    #3 0x7f6cbbbc6d9d in __cxa_decrement_exception_refcount
>>> /home/ben/development/llvm/trunk/libcxxabi/lib/../src/cxa_exception.cpp:519
>>>    #4 0x7f6cbbbc6d9d in __cxa_end_catch
>>> /home/ben/development/llvm/trunk/libcxxabi/lib/../src/cxa_exception.cpp:399
>>>    #5 0x47bc1b in main (/home/ben/development/test/teststdexcept+0x47bc1b)
>>>    #6 0x7f6cba9d9de4 in __libc_start_main
>>> /build/buildd/eglibc-2.17/csu/libc-start.c:260
>>>    #7 0x47b77c in _start
>>> (/home/ben/development/test/teststdexcept+0x47b77c)
>>> 
>>> 0x60300000efe0 is located 0 bytes inside of 28-byte region
>>> [0x60300000efe0,0x60300000effc)
>>> allocated by thread T0 here:
>>>    #0 0x465dd9 in operator new[](unsigned long)
>>> /home/ben/development/llvm/3.4/final/llvm.src/projects/compiler-rt/lib/asan/asan_new_delete.cc:54
>>>    #1 0x7f6cbb02770c in std::runtime_error::runtime_error(char const*)
>>> (/usr/lib/libc++.so.1+0x9170c)
>>>    #2 0x7f6cba9d9de4 in __libc_start_main
>>> /build/buildd/eglibc-2.17/csu/libc-start.c:260
>>> 
>>> 
>>> Any ideas what went wrong?
>>> 
>>> Cheers,
>>> 
>>> Ben
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
>> 
>> --
>> Alexander Potapenko
>> Software Engineer
>> Google Moscow
> 
> 
> 
> -- 
> Alexander Potapenko
> Software Engineer
> Google Moscow