STL "wrought with memory leaks"?

[Generic Usenet Account]

I have been using STL for a long time now, without any problems.
Recently we generated a purification report on our software using
Rational Purify, and we found some memory leaks. My colleague claims
that some of the memory leaks are due to the fact that "STL is wrought
with memory leaks". Of course I disagree. I think that there are no
"inherent leaks" with STL, but if used improperly, leaks will occur.

One common source of leak that I have seen is with 1:N maps. In this
case the value itself is a collection (say an STL set of values). Here
the normal approach of deleting an entry from the map [obtaining the
iterator using the find() operation and then invoking erase() on the
iterator] does not work since you don't want to delete the key-value
pair until you are sure that all the values have been deleted. In this
case, when you delete one of the values, you have to check whether
after deletion there are any values left. Only in the case where the
value portion is empty do you have to delete the key-value pair.
Sometimes due to an oversight, you may forget to delete the key-value
pair when the value collection is empty, resulting in a leak.

Are there any other sources of leaks, due to incorrect usage of STL,
that come to mind?

Regards,
Bhat

 

[Howard Hinnant]

I have been using STL for a long time now, without any problems.
Recently we generated a purification report on our software using
Rational Purify, and we found some memory leaks. My colleague claims
that some of the memory leaks are due to the fact that "STL is wrought
with memory leaks". Of course I disagree. I think that there are no
"inherent leaks" with STL, but if used improperly, leaks will occur.

One common source of leak that I have seen is with 1:N maps. In this
case the value itself is a collection (say an STL set of values). Here
the normal approach of deleting an entry from the map [obtaining the
iterator using the find() operation and then invoking erase() on the
iterator] does not work since you don't want to delete the key-value
pair until you are sure that all the values have been deleted. In this
case, when you delete one of the values, you have to check whether
after deletion there are any values left. Only in the case where the
value portion is empty do you have to delete the key-value pair.
Sometimes due to an oversight, you may forget to delete the key-value
pair when the value collection is empty, resulting in a leak.

Are there any other sources of leaks, due to incorrect usage of STL,
that come to mind?

Storing heap based pointers into containers and then mistakenly
believing that the container will own the pointer is a classic mistake.

Use of strstream without extreme care can lead to memory leaks (you've
got to remember to freeze(false) all the time). If you're not familiar
with this issue, just avoid strstream and prefer stringstream
(<sstream>) instead.

Purify (and other leak checkers) have been known to report false
positives for objects that do lazy initialization. The C++ I/O streams
usually fall into this category. They allocate some resources on first
use and then keep those resources around for later use (they are not
required to do this, it is just a typical implementation strategy).

And of course the number 1 cause of memory leaks is always "somebody
else's code". ;-)

-Howard

 

[Mark]

I have been using STL for a long time now, without any problems.
Recently we generated a purification report on our software using
Rational Purify, and we found some memory leaks. My colleague claims
that some of the memory leaks are due to the fact that "STL is wrought
with memory leaks". Of course I disagree. I think that there are no
"inherent leaks" with STL, but if used improperly, leaks will occur.

One common source of leak that I have seen is with 1:N maps. In this
case the value itself is a collection (say an STL set of values). Here
the normal approach of deleting an entry from the map [obtaining the
iterator using the find() operation and then invoking erase() on the
iterator] does not work since you don't want to delete the key-value
pair until you are sure that all the values have been deleted. In this
case, when you delete one of the values, you have to check whether
after deletion there are any values left. Only in the case where the
value portion is empty do you have to delete the key-value pair.
Sometimes due to an oversight, you may forget to delete the key-value
pair when the value collection is empty, resulting in a leak.

Are there any other sources of leaks, due to incorrect usage of STL,
that come to mind?

Storing heap based pointers into containers and then mistakenly
believing that the container will own the pointer is a classic mistake.

Use of strstream without extreme care can lead to memory leaks (you've
got to remember to freeze(false) all the time). If you're not familiar
with this issue, just avoid strstream and prefer stringstream
(<sstream>) instead.

Purify (and other leak checkers) have been known to report false
positives for objects that do lazy initialization. The C++ I/O streams
usually fall into this category. They allocate some resources on first
use and then keep those resources around for later use (they are not
required to do this, it is just a typical implementation strategy).

And of course the number 1 cause of memory leaks is always "somebody
else's code". ;-)

-Howard

Maybe this helps explains it:

http://www.sgi.com/tech/stl/alloc.html

Mark

 

[Sven Rosvall]

One common source of leak that I have seen is with 1:N maps. In this
case the value itself is a collection (say an STL set of values). Here
the normal approach of deleting an entry from the map [obtaining the
iterator using the find() operation and then invoking erase() on the
iterator] does not work since you don't want to delete the key-value
pair until you are sure that all the values have been deleted. In this
case, when you delete one of the values, you have to check whether
after deletion there are any values left. Only in the case where the
value portion is empty do you have to delete the key-value pair.
Sometimes due to an oversight, you may forget to delete the key-value
pair when the value collection is empty, resulting in a leak.

You may want to use multimap for such cases.
Use std::multimap::equal_range() or std::equal_range() to find all
elements with the same key. Then you can search this range for the
element to remove. No special treatment required for removing the last
element with a given key.

Are there any other sources of leaks, due to incorrect usage of STL,
that come to mind?

In my experience, lack of knowledge is the greates source of leaks.
Josuttis The C++ Standard Library and Meyers Effective STL are good
resources. Design and code review are very useful for learning from
others in your team.
--