[LLVMbugs] [Bug 22606] New: leak in std/thread/futures/futures.shared_future/get.pass.cpp

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22606

            Bug ID: 22606
           Summary: leak in
                    std/thread/futures/futures.shared_future/get.pass.cpp
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: earthdok at google.com
                CC: eric at efcs.ca, kcc at google.com, llvmbugs at cs.uiuc.edu,
                    mclow.lists at gmail.com, samsonov at google.com
    Classification: Unclassified

Created attachment 13879
  --> http://llvm.org/bugs/attachment.cgi?id=13879&action=edit
reproducer

LeakSanitizer reports a flaky leak of __thread_struct + __thread_struct_impl in
this test:

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-asan/builds/175/steps/test.libcxx/logs/libc%2B%2B%3A%3Aget.pass.cpp

I've attached a reduced test case. To build:

../build/bin/clang++ -std=c++11 -nostdinc++
-I../llvm/projects/libcxx/test/support -include
../llvm/projects/libcxx/test/support/nasty_macros.hpp
-I../llvm/projects/libcxx/include -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS  -nodefaultlibs  -Llib/
-Wl,-rpath,/usr/local/google/home/earthdok/san/build-libcxx/lib -lc++ -lc++abi
-lgcc_eh -lc -lm -lpthread -lrt -lgcc_s -ldl -fsanitize=address -g
-fno-omit-frame-pointer repro.cpp


After adding some logging output, I believe that this is *not* an LSan issue.
Normally __thread_struct is allocated here:

    #0 0x4c1e6b in operator new(unsigned long) _asan_rtl_:35
    #1 0x4cee23 in void* std::__1::__thread_proxy<std::__1::tuple<void
(*)(std::__1::promise<void>), std::__1::promise<void> > >(void*)
/usr/local/google/home/earthdok/san/build-libcxx/../llvm/projects/libcxx/include/thread:346:33
    #2 0x4ab00e in __asan::AsanThread::ThreadStart(unsigned long,
__sanitizer::atomic_uintptr_t*) _asan_rtl_:25

and deleted from a TSD destructor here:

    #0 0x4c24eb in operator delete(void*) _asan_rtl_:3
    #1 0x7fbaca476ad5 in
std::__1::__thread_specific_ptr<std::__1::__thread_struct>::__at_thread_exit(void*)
/usr/local/google/home/earthdok/san/llvm/projects/libcxx/include/thread:146:5
    #2 0x7fbac95a5f81 in __nptl_deallocate_tsd
/build/buildd/eglibc-2.19/nptl/pthread_create.c:158:0


However, in those cases when there is a leak, the TSD destructor call doesn't
happen. Looks like there's a race between the global __thread_specific_ptr
destructor which runs on the main thread and calls pthread_key_delete(), and
the TSD destructor. If the pthread_key_delete() call happens first, the TSD
destructor is not run.

Now, we can probably work around this in LSan, but I'm not convinced this is
good behavior on part of libc++. Another option would be to hold
__thread_struct in a special kind of __thread_specific_ptr which wouldn't call
pthread_key_delete() on destruction.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150216/3509d5b4/attachment.html>