[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


            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>,

   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;

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

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