std::basic_stringstream
-
Memory leaks can nasty little buggers. X| They can give you a bad itch for a long time, but you cannot locate the itch exactly. We have had an interesting case recently, and forgive me if this is a repost: Our application, ( a mobile connection manager ), was leaking slowly but steadily. After a leaving it on during the night memory usage multiplied. Now, the first odd thing was that the debugger never detected any leaks on exit. Our first assumption was naturally that one of our objects was growing but that it was destroyed properly. After a few days we had narrowed the “leak” down to the usage monitor ( the class reporting network traffic ). But there the trail went cold. We could see nothing wrong with those few lines of code. Then we observed the next odd fact, it was only growing in the debug build ( but not release! ). Finally it turned out that the culprit was not our code at all, it was STL! ( the Microsoft implementation of it )
std::basic_stringstream< wchar_t > stream; // This leaksHere is a discussion on the MSDN forum. Apparently this has been fixed in SP1 for VS8. Two things though are beyond my comprehension, and I would be happy to learn something new: 1. How is it possible that the leaks go undetected by the debugger ? 2. A lot of people have discussed this bug on the web, but no-one mentions any difference between release & debug. :confused: MS even mentions the release of new runtime libraries with the service pack. How come I do not get this leak in release build ? Cheerz & Thanks Adam_____________________________________ Action without thought is not action Action without emotion is not life
-
Memory leaks can nasty little buggers. X| They can give you a bad itch for a long time, but you cannot locate the itch exactly. We have had an interesting case recently, and forgive me if this is a repost: Our application, ( a mobile connection manager ), was leaking slowly but steadily. After a leaving it on during the night memory usage multiplied. Now, the first odd thing was that the debugger never detected any leaks on exit. Our first assumption was naturally that one of our objects was growing but that it was destroyed properly. After a few days we had narrowed the “leak” down to the usage monitor ( the class reporting network traffic ). But there the trail went cold. We could see nothing wrong with those few lines of code. Then we observed the next odd fact, it was only growing in the debug build ( but not release! ). Finally it turned out that the culprit was not our code at all, it was STL! ( the Microsoft implementation of it )
std::basic_stringstream< wchar_t > stream; // This leaksHere is a discussion on the MSDN forum. Apparently this has been fixed in SP1 for VS8. Two things though are beyond my comprehension, and I would be happy to learn something new: 1. How is it possible that the leaks go undetected by the debugger ? 2. A lot of people have discussed this bug on the web, but no-one mentions any difference between release & debug. :confused: MS even mentions the release of new runtime libraries with the service pack. How come I do not get this leak in release build ? Cheerz & Thanks Adam_____________________________________ Action without thought is not action Action without emotion is not life
Actually, I was fooled by the same leak. Only that I believed that "something as important as stringstream can't leak", so I dismissed that thought and happily looked for the leak in all my code. Until I thought that maybe checking it out on the web couldn't hurt - et voila, it WAS stringstream and it WAS leaking. Someone took the time of dissecting the standard implementation and posting an explanation of the leak somewhere. If I can find it again, I will post it here.
Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
-
Actually, I was fooled by the same leak. Only that I believed that "something as important as stringstream can't leak", so I dismissed that thought and happily looked for the leak in all my code. Until I thought that maybe checking it out on the web couldn't hurt - et voila, it WAS stringstream and it WAS leaking. Someone took the time of dissecting the standard implementation and posting an explanation of the leak somewhere. If I can find it again, I will post it here.
Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
Sebastian Schneider wrote:
Actually, I was fooled by the same leak. Only that I believed that "something as important as stringstream can't leak", so I dismissed that thought and happily looked for the leak in all my code. Until I thought that maybe checking it out on the web couldn't hurt - et voila, it WAS stringstream and it WAS leaking.
MS never payed much attention to the
std::stuff. For them MFC was (still is and will be) the 'Standard' C++ library. -
Sebastian Schneider wrote:
Actually, I was fooled by the same leak. Only that I believed that "something as important as stringstream can't leak", so I dismissed that thought and happily looked for the leak in all my code. Until I thought that maybe checking it out on the web couldn't hurt - et voila, it WAS stringstream and it WAS leaking.
MS never payed much attention to the
std::stuff. For them MFC was (still is and will be) the 'Standard' C++ library.Well, that might have been true with VS 6.0, where STL was abyssal. But since 2003 and definitely since 2005 STL and the compilers template implementation is one of the best (not the best, mind you, but ahead of most of the competition). Magnus