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:
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?
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
Can I help?
Are there instructions on how to run the full test suite?
I help out with Clang releases so I should have most of it ready to go.
Ben
The results (from libcxx/test/testit) before and after the modification look like this:
