[LLVMbugs] [Bug 15638] New: Possible memory leak when starting a new thread

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15638
           Summary: Possible memory leak when starting a new thread
           Product: libc++
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: louis.dionne92 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

While looking at the code in <thread>, I ran into the following:

template <class _Fp>
void* __thread_proxy(void* __vp) {
    __thread_local_data().reset(new __thread_struct);
    std::unique_ptr<_Fp> __p(static_cast<_Fp*>(__vp));
    .....
}

template <class _Fp, class ..._Args, class>
thread::thread(_Fp&& __f, _Args&&... __args) {
    typedef tuple<typename decay<_Fp>::type, typename decay<_Args>::type...>
_Gp;
    _VSTD::unique_ptr<_Gp> __p(new _Gp(__decay_copy(_VSTD::forward<_Fp>(__f)),
                               
__decay_copy(_VSTD::forward<_Args>(__args))...));
    int __ec = pthread_create(&__t_, 0, &__thread_proxy<_Gp>, __p.get());
    if (__ec == 0)
        __p.release();
    else
        __throw_system_error(__ec, "thread constructor failed");
}

Unless I am mistaken, if the allocation fails on the first line of
__thread_proxy, __vp will never be freed because it is not yet owned by
the unique_ptr. Simply changing the order of the first two lines in
__thread_proxy would fix the issue.

-- 
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/20130401/39061472/attachment.html>