[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