[LLVMbugs] [Bug 20335] New: basic_string leaks memory when move-constructed with unequal allocator

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Jul 16 16:22:48 PDT 2014


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

            Bug ID: 20335
           Summary: basic_string leaks memory when move-constructed with
                    unequal allocator
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: tkoeppe at google.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Created attachment 12780
  --> http://llvm.org/bugs/attachment.cgi?id=12780&action=edit
Demonstrates memory leak in std::basic_string

I believe there's a memory leak in the current (213208) libc++ implementation
of basic_string when a string is move-constructed from another string but with
an unequal allocator. Briefly, here's how to produce it:

   using astring = std::basic_string<char, std::char_traits<char>,
                                     StatefulAllocator<T>>;

   int main()
   {
       StatefulAllocator<void> a(STATE1), b(STATE2);  // assume a != b

       astring s("looooooooooooooooooooooooooooooong", a); // no SSO

       astring t(std::move(s), b);   // leak: data of s is not released
   }

I'm attaching an example (run it through valgrind to see the leak).

I believe that the problem lies in "string:2139":

    if (__a == __str.__alloc() || !__str.__is_long())
        __r_.first().__r = __str.__r_.first().__r;
    else
        __init(_VSTD::__to_raw_pointer(__str.__get_long_pointer()),
__str.__get_long_size()); 
    __str.__zero();

If the allocators are not equal, i.e. the first branch isn't taken; then it
seems that __init() will copy the string data with the new allocator, but never
release the old memory. The pointer to the old memory is wiped immediately by
__str.__zero();.

-- 
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/20140716/2c1b89a5/attachment.html>


More information about the llvm-bugs mailing list