   Help tracking down memory leak with vector/list
  I'm showing only a couple memory leaks when the program exits.  When I set a breakpoint on the allocation number, it's deep down in STL and traces back to the vector class.  I know it's a problem with how I'm using it, but I'm not sure what's wrong.Basically I have a vector of a list.  This is ok, right?  Like this:typedef std::list< AXVertexBuffer* > VertexBufferList;typedef std::vector< VertexBufferList > Buffer2DArray;I am creating the buffers by looping through and creating the list, and then attaching the list to the vector like so:for(unsigned int i=0; i<=6; i++) {VertexBufferList BufferVector;for(unsigned int j=0; j<NumBuffers; j++) {AXVertexBuffer *Buffer = new AXVertexBuffer;/* init stuff*/BufferVector.push_back(Buffer);}_VertexBuffers.push_back(BufferVector);}And I am deleting it like so.  I have to do it this way because FreeUploadedVertexData and FreeVertexBuffer pushes the buffer to the front of the list and makes any iterator invalid.  I have a feeling my error is in here.  I have debugged though and this does go through every node, since every time the node is pushed to the front, back() successfully gets the next one./*Delete vertex buffers */for(unsigned int i=0; i<(unsigned int)_VertexBuffers.size(); i++) {/*We do it this way because FreeUploadedVertexData changes theorder of the list and would make our iterator invalid */for(unsigned int j=0; j<(unsigned int)_VertexBuffers.size(); j++) {AXVertexBuffer *Buffer = _VertexBuffers.back();UnlockVertexBuffer(Buffer);if(Buffer->Owner) Buffer->Owner->FreeUploadedVertexData();else FreeVertexBuffer(Buffer);SafeDelete(Buffer);}_VertexBuffers.clear();}_VertexBuffers.clear();Can anyone see a problem with this?   
  Shouldn't this line:AXVertexBuffer *Buffer = _VertexBuffers.back();be:AXVertexBuffer *Buffer = _VertexBuffers[j];?;Quote:Original post by ldeejShouldn't this line:AXVertexBuffer *Buffer = _VertexBuffers.back();be:AXVertexBuffer *Buffer = _VertexBuffers[j];?Nope, because you can't randomly access a list.  See my note right above that code.  The functions FreeUploadedVertexData and FreeVertexBuffer push the buffer to the front of the list, so back() always will retrieve the next buffer.  Thanks though.   ;  Out of curiosity, why are you doing this:And I am deleting it like so. I have to do it this way because FreeUploadedVertexData and FreeVertexBuffer pushes the buffer to the front of the list and makes any iterator invalid. I have a feeling my error is in here. I have debugged though and this does go through every node, since every time the node is pushed to the front, back() successfully gets the next one.FreeVertexBuffer knows about the global list?A couple of things that can help:If these are DX vertex buffers check the internal count on Release, make sure that you do not have copies elsewhere that have AddRef'd the buffer intentionally or by accident.Basically there are two places where the problem might be happening:Your deallocation loop is not deallocating stuff correctly (Based on your description this does not seem to be the case)The vertex buffer internal data is not released because the ref count if > 0 after your loop, this might mean some other code is doing an AddRef without a Release (Assuming you are using DX)Hope this helps   ;  clear() does not necessarily release the memory owned by the container: it depends on the implementation and the allocator being used. If your containers are global variables, it is very possible that the memory is finally released some time after your leak check.What STL implementation are you using?   ;  no matterwithout threads, most important is deallocationKuphryn   ;  I thought this went through ealier, but I guess it didn't... (fickle internet here, blah)These aren't DX buffers, they are simply abstract buffers.  Internally I create a few large DX buffers and manage it myself with these buffers.Thanks for all the help.  I tracked down the memory leak to somewhere else, and it's exiting all cleanly now.  It was as simple as not deleting something.  I guess the allocation request number was different when I ran it with the checkpoint before.  Sorry for wasting your time, and thanks :)By the way, if you read this Fruny, I'm interested, how many different STL implementations are there?  I'm just using the standard with Visual Studio 2003.   ;  Each compiler can have a different implementation, and there are implementations that work with multiple compilers.VS 2003/2005 ship with two different versions of Dikumware's STL, which is the default and the one you are using right now.There are some open source ones, i.e. STLPortIntel and SGI might have implementations as well.   ;  Changing the size of a std::vector that contains expensive-to-copy structures like std::lists is not a good idea.std::vectors are very cavalere about copying their contents around.  On average, each call to push_back() on a std::vector costs the copying of one random element already in the vector.(Every 1/n calls it causes a reallocation, which causes all n elements to be reallocated).I would advise either storing (auto?)pointers to std::lists, or using a std::deque (which has slower random access, but doesn't copy the data around on you).;Quote:Original post by NotAYakkI would advise either storing (auto?)pointers to std::lists, or using a std::deque (which has slower random access, but doesn't copy the data around on you).I assume you mean "(smart?)pointers", since auto_ptrs cannot be stored in standard containers.Σnigma   