STL "wrought with memory leaks"?

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

re: STL "wrought with memory leaks"?

In article <1115405946.474675.195200@z14g2000cwz.googlegroups .com>,
"Generic Usenet Account" <usenet@sta.samsung.com> wrote:
[color=blue]
> 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?[/color]

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

re: STL "wrought with memory leaks"?

Howard Hinnant wrote:[color=blue]
> In article <1115405946.474675.195200@z14g2000cwz.googlegroups .com>,
> "Generic Usenet Account" <usenet@sta.samsung.com> wrote:
>
>[color=green]
>>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?[/color]
>
>
> 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[/color]

Maybe this helps explains it:

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

Mark