[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