Solved

about STL Memory leak!

Posted on 2002-06-06
7
1,180 Views
Last Modified: 2013-12-14
 When use MSVC6 to complile programms with STLPort, I found MEMORY LEAK. And I saw FAQ on www.SGI.com, it says Bounds Checker is wrong. I donnot know which is right, I must use STL to write a service programm.

 will STLPort or SGI's STL occure memory leak?
0
Comment
Question by:clarkent
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 2
7 Comments
 
LVL 22

Expert Comment

by:nietod
ID: 7058873
The link you pasted does not seem to work.

The boundschecker problem I am aware of is definitely a "problem" with bounds checker.   (Its not a serious problem).  bound checker will report 1 memory leak in the program that is not really a leak it is memory used by the VC RTL.  I am not sure this is the problem you are referring to.

I think its unlikely that any well-written STL will have a memory leak.  
0
 
LVL 4

Expert Comment

by:IainHere
ID: 7059421
nietod, the FAQ is here: http://www.sgi.com/tech/stl/FAQ.html

And says bounds checker is wrong in a certain case.  It will certainly be referring to SGI's implementation of the STL.

clarkent:
>>I think its unlikely that any well-written STL will have a memory leak.
I thought nietod's point was worth restating.  The STL is widely used, even the implementation that came with MSVC++.  It works - I use it :-)

For more information, it might be worth posting the specific error message, although I think it is unlikely you will find anyone here who is familiar enough with the STLPort and BoundsChecker to point you in the exact direction of the detected "error".
0
 
LVL 22

Expert Comment

by:nietod
ID: 7059507
The memory leaks discussed in the FAW are not a concern.   They are not really leaks.  This is a common method of optimization.   Many STL implimentatiosn do this.  There are lots of STL classes that repeatedly allocate and delete data of the same size.  (A map for example may need to be adding and deleting lots of nodes as the map is changed.)  These allocations and deletions can be inefficient and can lead to a lot of memory fragmentation.   Many implimentations will not delete the memory when it is no longer needed, instead they store a record of it somewhere (usually in a linked list, and the memory itself stores the linked list so it is very space efficient.).  Then when a block is needed again it just grabs it from the list.  This is much faster than forcing the system to find a block.  (Because the STL stores blocks of exactly the right size so it can take the first one in the list, whereas the RTL woudl have to seach the heap for a block of about the right size.)

so I woudl not worry about this at all.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 

Author Comment

by:clarkent
ID: 7060735
Thanks a lot to everyone! Below is an test programm.
#include <CrtDbg.h>
bool FuncA();
int main()
{
  FuncA();
  _CrtDumpMemoryLeaks();
  return 1;
}

bool FuncA()
{
  string myString="abc";
  return true;
}
// --------------------- Bounds Checker output:
Memory leak: 320 bytes allocated by HeapAlloc in sbheap.c(102) HANDLE:0X02151E90
Memory leak: 1328 bytes allocated by operator new in ..\\stlport\\stl\\_alloc.c(270) HANDLE:0X02156EC0
Memory leak: 448 bytes allocated by operator new in ..\\stlport\\stl\\_alloc.c(224) HANDLE:0X02161540
//---------------------- _CrtDumpMemoryLeaks output:
Detected memory leaks!
Dumping objects ->
{69} normal block at 0x02162C90, 144 bytes long.
 Data: <tsK             > 74 73 4B 00 00 00 00 00 00 00 00 00 00 00 00 00
{68} normal block at 0x02162D50, 144 bytes long.
 Data: <tsK             > 74 73 4B 00 00 00 00 00 00 00 00 00 00 00 00 00
{67} normal block at 0x02162E10, 144 bytes long.
 Data: <tsK             > 74 73 4B 00 00 00 00 00 00 00 00 00 00 00 00 00
{66} normal block at 0x02162ED0, 144 bytes long.
 Data: <tsK             > 74 73 4B 00 00 00 00 00 00 00 00 00 00 00 00 00
{65} normal block at 0x02162F90, 92 bytes long.
 Data: < sK  ?L  /      > EC 73 4B 00 F0 3F 4C 00 BC 2F 16 02 BF BF BF BF
{64} normal block at 0x02161040, 92 bytes long.
 Data: < sK  ?L l       > EC 73 4B 00 F0 3F 4C 00 6C 10 16 02 BF BF BF BF
{63} normal block at 0x021610D0, 92 bytes long.
 Data: < sK  ?L         > EC 73 4B 00 D0 3F 4C 00 FC 10 16 02 BF BF BF BF
{62} normal block at 0x02161160, 92 bytes long.
 Data: <(tK  ?L         > 28 74 4B 00 B0 3F 4C 00 8C 11 16 02 BF BF BF BF
{61} normal block at 0x021611F0, 796 bytes long.
 Data: <September       > 53 65 70 74 65 6D 62 65 72 00 BF BF BF BF BF BF
{60} normal block at 0x02161540, 452 bytes long.
 Data: <Thu mbe Wed mbe > 54 68 75 00 6D 62 65 00 57 65 64 00 6D 62 65 00
{59} normal block at 0x02156EC0, 1332 bytes long.
 Data: <%a %b %e %H:%M:%> 25 61 20 25 62 20 25 65 20 25 48 3A 25 4D 3A 25
{58} normal block at 0x02161730, 348 bytes long.
 Data: <PM      Wed M:% > 50 4D 00 CD CD CD CD CD 57 65 64 00 4D 3A 25 00
{57} normal block at 0x021618C0, 324 bytes long.
 Data: <C       Sun     > 43 00 CD CD CD CD CD CD 53 75 6E 00 CD CD CD CD
Object dump complete.
0
 
LVL 22

Accepted Solution

by:
nietod earned 75 total points
ID: 7060929
You can probably ignore the leaks reported by _crtDumpMemoryLeaks.  That function is useful only after the RTL has cleaned up, whick does not occur until after main() ends and all the static variables are destroyed.  i.e. you are clalling it much too soon.

You can _CrtSetDbgFlg() to have the RTL call it at the appropriate time..

I suspect the problems reported by bounds checker are not a problem--but there is no way to be sure.

If you have dobuts, you can use the STL that comes with VC.  That doesn't have any serious memory leak problems--none I've ever encountered.
0
 

Author Comment

by:clarkent
ID: 7061011
nietod,Thank you. I must use the thread safe STL and it running as a service. Can you suggest me more?
It is my first time ask question here.
0
 
LVL 22

Expert Comment

by:nietod
ID: 7061687
The VC STL is thread safe.  (I use it in multiple threads.)   At least, it is safe if you take precautions to synchorize the objects your create with it.  i.e. if you share an STL string between threads, you need to synchronize access to that  to that STL string.   However, if you create sperate STL strings in seperate threads, you don't need to worry about them--even if the STL strings share data between threads.

I'm not sure what sort of thread safety SGI is providing, but I doubt it is any more or less than this.  Is there a reason you chose this STL?
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

IntroductionThis article is the second in a three part article series on the Visual Studio 2008 Debugger.  It provides tips in setting and using breakpoints. If not familiar with this debugger, you can find a basic introduction in the EE article loc…
How to install Selenium IDE and loops for quick automated testing. Get Selenium IDE from http://seleniumhq.org Go to that link and select download selenium in the right hand columnThat will then direct you to their download page.From that page s…
THe viewer will learn how to use NetBeans IDE 8.0 for Windows to perform CRUD operations on a MySql database.
The viewer will learn how to use and create keystrokes in Netbeans IDE 8.0 for Windows.

734 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question