[LLVMbugs] [Bug 22021] New: libc++ std::ostrstream leaks memory.
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Tue Dec 23 16:01:38 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=22021
Bug ID: 22021
Summary: libc++ std::ostrstream leaks memory.
Product: libc++
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: ruffianeo at googlemail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
Running either of the two programs below shows, that std::ostrstream leaks
large amounts of memory, while std::ostringstream does not. While not shown
here, it possibly also overwrites memory.
The only difference between those 2 programs is the switch from strstream to
sstream and from std::ostrsream to std::ostringstream.
compiled with:
clang++ -std=c++11 -stdlib=libc++ buggy.cpp -o buggy
and
clang++ -std=c++11 -stdlib=libc++ not_buggy.cpp -o not_buggy
respectively.
Then run as:
valgrind ./buggy
and
valgrind ./not_buggy.
Buggy.cpp
// Uses strstream header and std::ostrstream
#include <iostream>
#include <strstream>
#include <fstream>
#include <stdint.h>
static std::string MessageComposer( uint32_t index )
{
std::ostrstream stm;
stm << "This is message #" << index << "." << std::endl;
return stm.str();
}
int main( int argc, char * argv[] )
{
for( uint32_t i = 0; i < 100; ++i )
{
std::cout << MessageComposer(i);
}
return 0;
}
not_buggy.cpp
// uses sstream and std::ostringstream.
#include <iostream>
#include <sstream>
#include <fstream>
#include <stdint.h>
static std::string MessageComposer( uint32_t index )
{
std::ostringstream stm;
stm << "This is message #" << index << "." << std::endl;
return stm.str();
}
int main( int argc, char * argv[] )
{
for( uint32_t i = 0; i < 100; ++i )
{
std::cout << MessageComposer(i);
}
return 0;
}
Valgrind summary for the buggy version:
==26471==
==26471== HEAP SUMMARY:
==26471== in use at exit: 413,696 bytes in 101 blocks
==26471== total heap usage: 101 allocs, 0 frees, 413,696 bytes allocated
==26471==
==26471== LEAK SUMMARY:
==26471== definitely lost: 409,600 bytes in 100 blocks
==26471== indirectly lost: 0 bytes in 0 blocks
==26471== possibly lost: 0 bytes in 0 blocks
==26471== still reachable: 4,096 bytes in 1 blocks
==26471== suppressed: 0 bytes in 0 blocks
==26471== Rerun with --leak-check=full to see details of leaked memory
==26471==
==26471== For counts of detected and suppressed errors, rerun with: -v
==26471== Use --track-origins=yes to see where uninitialised values come from
==26471== ERROR SUMMARY: 100 errors from 1 contexts (suppressed: 0 from 0)
Valgrind summary for the not_buggy version:
==26474==
==26474== HEAP SUMMARY:
==26474== in use at exit: 4,096 bytes in 1 blocks
==26474== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==26474==
==26474== LEAK SUMMARY:
==26474== definitely lost: 0 bytes in 0 blocks
==26474== indirectly lost: 0 bytes in 0 blocks
==26474== possibly lost: 0 bytes in 0 blocks
==26474== still reachable: 4,096 bytes in 1 blocks
==26474== suppressed: 0 bytes in 0 blocks
==26474== Rerun with --leak-check=full to see details of leaked memory
==26474==
==26474== For counts of detected and suppressed errors, rerun with: -v
==26474== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--
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/20141224/f7ebf2ec/attachment.html>
More information about the llvm-bugs
mailing list