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

[Alexander Potapenko]

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