std::list and the heap

[MikeB]

Hi,

I've observed some odd behaviour in the std::list supplied with our
development system. In the accompanying code, the list has at most one
string on it, yet the program eventually runs out of heap.
However, if instead of using a std::list I use a std::deque, the program
doesn't run out of heap. Can anyone explain the behaviour of std::list or is
it a bug ?

TIA,
MikeB


#include <string>
#include <list>

int main()
{
std::list< std::string> strings;

for( ;
{
strings.push_back( "Hello, world");

strings.pop_front();
}
}

 

[Alf P. Steinbach]

* MikeB:

I've observed some odd behaviour in the std::list supplied with our
development system. In the accompanying code, the list has at most one
string on it, yet the program eventually runs out of heap.
However, if instead of using a std::list I use a std::deque, the program
doesn't run out of heap. Can anyone explain the behaviour of std::list or is
it a bug ?

If it really runs out of heap then it is IMHO a bug.

However, with MSVC I noted that the debug heap reports ever increasing
heap usage in number of bytes, while number of blocks allocated was
constant and no memory leak reported (for your code, instrumented).

So perhaps it's just that you've seen that byte counter (which is either
a bug in the debug heap support, or incorrectly documented) increasing?

 

[MikeB]

So perhaps it's just that you've seen that byte counter (which is either
a bug in the debug heap support, or incorrectly documented) increasing?

Alf,

We aren't using MSVC - we use ARM/RVCT. I started to look into this because
I was getting reports that our system was running out of heap. The ARM
runtime provides functions for us to examine the state of the heap so I
instrumented the code using these functions. I'd say that the statistics we
saw were in line with a steady decrease in the amount of free heap. However,
I'll take your observations on board and have another look at the figures.

What intrigued me though was the fact that if I used a deque, the amount of
free heap stayed constant.

As a matter of interest, how did you instrument the code in MSVC ?

Rgds,
MikeB

 

[Alf P. Steinbach]

* MikeB:

What intrigued me though was the fact that if I used a deque, the amount of
free heap stayed constant.

That's not a big surprise: a deque can make do with an array as
storage, instead of a linked list (it has to reallocate when the
size increases above its 'capacity', note that a list, being heap
based, doesn't have a 'capacity').

As a matter of interest, how did you instrument the code in MSVC ?

In various ways; when I wrote the reply the code looked like shown
below; I'm not sure what the last thing I checked was:


#include <iostream>
#include <ostream>
#include <string>
#include <list>
#include <deque>
#include <CRTDBG.H>

#define CONTAINER std::list

int main()
{
// Send all reports to STDOUT
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT );


{
CONTAINER< std::string> strings;
_CrtMemState initialMemState = {0};
_CrtMemCheckpoint( &initialMemState );

for( int i = 1; i <= 20; ++i)
{
strings.push_back( "Hello, world");
//double *p = new double( 3.14 );
_CrtMemState memState = {0};
_CrtMemCheckpoint( &memState );
std::cout << memState.lTotalCount << std::endl;
strings.pop_front();
//delete p;
}
_CrtMemDumpAllObjectsSince( &initialMemState );
}
}

 

[MikeB]

If it really runs out of heap then it is IMHO a bug.

Alf,

I've received an email from our supplier confirming that the observed
behaviour occurs as a result of a defect in the library.

Many thanks for your help.
MikeB