#include <vector>
using namespace std;
vector<int*> the_vector;
vector<int*>::iterator the_iterator;
int main()
{
{
for( int i = 0; i < 10; i++ )
the_vector.push_back( new int() );
the_iterator = the_vector.begin();
while( the_iterator != the_vector.end() )
{
delete *the_iterator++;
}
the_vector.clear();
}
_CrtDumpMemoryLeaks();
return 1;
}
Memory Leak or just STL?
Author
Hey, simple question and possibly just as simple answer but the code below should not produce any leaks and i'm guessing it doesn't as I do delete the memory with the iterator but why does _CrtDumpMemoryLeaks() output that there are leaks? Is it just something inside of STL internally not yet gone out of scope; thats why it says there are leaks yet there are not?
Thanks.
The vector you declared as a global variable hasn't been destroyed when you call _CrtDumpMemoryLeaks(). This is a problem you'll have with all global objects that allocate memory, not just STL objects. You may have better luck using _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ) instead of _CrtDumpMemoryLeaks().
Author
Thanks mate. So would this problem also occur for vectors declared inside of classes also etc?
It can happen with static member variables (which are basically global variables with different scoping rules). Non-static member variables can leak if you don't define your copy constructors, assignment operators or destructors properly or if you just don't delete the objects.
Author
Thanks. Yeah I know about static variables ;) How has an assignment operator, copy ctor got to do with memory leaks? :S Obviously a dtor to delete data members which are pointers, operators and copy ctor I only do if I need to i.e. to take a deep copy of a pointer inside of the class. If I didn't overload those operators or a copy ctor it would just keep taking a shallow copy, if you then delete the RHS object then all you'd end up with dangling pointers in the other objects...what exactly are you on about lol? :) Thanks.
DrunkenBrit,
As explained by SiCrane, what is happening is your variable hasn't been destroyed yet.
On most compilers if you don't change the entry point to a program the CRT(c-run time library) will initialize itself and then call main(). To see this put a break point in your program and view the call stack. During the initialization of the CRT the code will peek into the data segment of the executable and find the table of static constructors. These constructors get called before main is ever executed. When you exit your main function it will shutdown the CRT. During that shutdown all the destructors are iterated over and their functions are called.
The point is, that global variables will get constructed before your program is ran and destroyed after your program is finished running.
-= Dave
As explained by SiCrane, what is happening is your variable hasn't been destroyed yet.
On most compilers if you don't change the entry point to a program the CRT(c-run time library) will initialize itself and then call main(). To see this put a break point in your program and view the call stack. During the initialization of the CRT the code will peek into the data segment of the executable and find the table of static constructors. These constructors get called before main is ever executed. When you exit your main function it will shutdown the CRT. During that shutdown all the destructors are iterated over and their functions are called.
The point is, that global variables will get constructed before your program is ran and destroyed after your program is finished running.
-= Dave
If you want to exclude statics from your memory leak test and just check for specific pieces of code you can use _CrtMemDifference();
[edit]
For correctness, as SiCrane pointed out, this will not "exclude" whole variables in your app. It will prevent false positives on statically allocated memory such as static classes.
[/edit]
Somehow in the difference struct it stores which allocation has leaked. It's a bit hard to interpret, but there's probably a way to make a nice printout of it. I use this in unit tests so I have not needed that feature yet.
[Edited by - Structural on July 17, 2007 12:52:19 AM]
[edit]
For correctness, as SiCrane pointed out, this will not "exclude" whole variables in your app. It will prevent false positives on statically allocated memory such as static classes.
[/edit]
_CrtMemState before, after, difference;_CrtMemCheckpoint( &before );char* leakMePlenty = new char[100];_CrtMemCheckpoint( &after );if ( _CrtMemDifference( &difference, &before, &after) ){ TS_FAIL("SIGNIFICANT MEMORY DIFFERENCE");}Somehow in the difference struct it stores which allocation has leaked. It's a bit hard to interpret, but there's probably a way to make a nice printout of it. I use this in unit tests so I have not needed that feature yet.
[Edited by - Structural on July 17, 2007 12:52:19 AM]
Quote:Original post by DrunkenBrit
Thanks. Yeah I know about static variables ;) How has an assignment operator, copy ctor got to do with memory leaks? :S Obviously a dtor to delete data members which are pointers, operators and copy ctor I only do if I need to i.e. to take a deep copy of a pointer inside of the class. If I didn't overload those operators or a copy ctor it would just keep taking a shallow copy, if you then delete the RHS object then all you'd end up with dangling pointers in the other objects...what exactly are you on about lol? :) Thanks.
Here's a starting point.
Author
Thanks SiCrane, Structural and David Neubelt :)
Zahlman...wtf are you on about? lol I don't know what your point is with your post...Maybe I have to be Canadian to understand it? lol.
Zahlman...wtf are you on about? lol I don't know what your point is with your post...Maybe I have to be Canadian to understand it? lol.
Quote:Original post by Structural
If you want to exclude statics from your memory leak test and just check for specific pieces of code you can use _CrtMemDifference();
That doesn't exclude statics. You can still get a false positive from a global if you do something like global_vector.reserve(global_vector.capacity() + 1); between the check points.
If you want an example of how an improperly written copy constructor or assignment operator can cause a leak: consider an object that contains a COM interface that AddRef()'s the new interface pointer, but forgets to Release() the old interface pointer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
