🔒 Locked

Problems deleting dynamically allocated memory..

Started by Alex Swinney Nov 16, 2004 at 9:21 AM 12 replies 1.8k views

Original Post

Nov 16, 2004 at 9:21 AM

This is really embarassing..somehow my program (VS.NET) isn't allowing me to delete dynamically allocated memory. I'm sure I'm missing something..but here's what I've got:


	ter = new TerrainVertex[desc.Size/sizeof(TerrainVertex)+1];
	ter2 = new TerrainVertex[desc.Size/sizeof(TerrainVertex)+1];

	delete [] ter;
	delete [] ter2;

That is all in one function, and this function is called once. 'ter' and 'ter2' are both of type TerrainVertex, which is defined by my program. I had my destructor with this as it's contents: delete [] this; but that still didn't delete the memory..what should go in there? It is giving me this assertion error (first, there are others that follow): _BLOCK_TYPE_IS_VALID(pType->nBlockUse)

VolkerG

Nov 16, 2004 at 9:29 AM

May it be that the code between these lines demages the allocated blocks?

SiCrane

Mod

473

SiCrane

Nov 16, 2004 at 9:33 AM

Don't call delete this in a destructor. Freeing the memory is the responsibility of whatever invoked the destructor, not the destructor. Only delete objects that the class has ownership of; ex: buffers it allocated itself.

Alex Swinney

Author

Alex Swinney

Nov 16, 2004 at 9:42 AM

Quote:
Original post by VolkerG
May it be that the code between these lines demages the allocated blocks?

The code between the new and delete uses the two variables to read one DX vertex buffer and write to another DX vertex buffer.

Isn't it a little asinine to have to have an empty destructor? If I remove the destructor entirely, I get an error, but it has to be empty or I get an error..

snk_kid

131

snk_kid

Nov 16, 2004 at 9:46 AM

Quote:
Original post by Alex Swinney
Isn't it a little asinine to have to have an empty destructor? If I remove the destructor entirely, I get an error, but it has to be empty or I get an error..

if your destructor doesn't have anything to do then don't declare & define one, one will be implicitly defined.

you only need to explicitly define a destructor to release resources most commonly when a class acquires a resource itselfs usually in the constructor e.g.

struct foo {  int* ptr;  foo(int n): ptr(new [n]) {} //aquire resource  ~foo() { delete[] ptr; } //release resource};

OrenGL

Nov 16, 2004 at 9:46 AM

If you make an independent 5 line program and run these lines does it work? If not have a look into the TerrainVertex destructor if it does work the problem is not these lines but in something else.

lemurion

Nov 16, 2004 at 9:50 AM

Quote:
Original post by Alex Swinney
'ter' and 'ter2' are both of type TerrainVertex

shouldn't they be of type TerrainVertex * ??

hope that helps !
Matt

Alex Swinney

Author

Alex Swinney

Nov 16, 2004 at 9:52 AM

Quote:
Original post by lemurion
Quote:
Original post by Alex Swinney
'ter' and 'ter2' are both of type TerrainVertex

shouldn't they be of type TerrainVertex * ??

hope that helps !
Matt

Sorry, they are, brainfart.

Alex Swinney

Author

Alex Swinney

Nov 16, 2004 at 9:59 AM

Ok, does anyone know DirectX?

I removed the lines where I declared the size of the array, and let them be determined by the vertex buffer lock function. I also removed the delete [] calls. I do not get an unfreed memory error from DXDebug..so I am wondering if lock allocates and deletes?

[EDIT] Nevermind, I get an unfreed memory error upon exit..

So, if I remove the delete calls, it works, but memory is unfreed and if I leave them in there I get this crap:
_BLOCK_TYPE_IS_VALID(pType->nBlockUse)

Ugh..

Agony

177

Agony

Nov 16, 2004 at 10:21 AM

The pointer you pass to Lock should not initially refer to allocated memory. The pointer gets set to memory already allocated by DirectX. And don't forget to call Unlock on the vertex buffer afterwards.

void Function(){  VertexStruct* pVertices;  pVertexBuffer->Lock(0, 0, &pVertices, 0);  //Do stuff to pVertices  pVertexBuffer->Unlock();}

Fruny

203

Fruny

Nov 16, 2004 at 10:44 AM

Quote:
Original post by Alex Swinney
The code between the new and delete uses the two variables to read one DX vertex buffer and write to another DX vertex buffer.

Let me draw you a picture:

The assertion checks that the block header (which contains, among other things, the number of array elements allocated, so that delete[] does the right thing), is valid. You trashed it with your DirectX data, the assertion fails.

khalligan

Nov 16, 2004 at 11:15 AM

Im no DirectX genius, but heres what Id do:

The pVertices void pointer in Lock() function is normally NULL

void *pVertices = NULL;pVertexBuffer->Lock(0, 0, &(void**)pVertices, 0);ter = new TerrainVertex[desc.Size/sizeof(TerrainVertex)+1];ter2 = new TerrainVertex[desc.Size/sizeof(TerrainVertex)+1];// Do stuff to vertices, careful not to go outside arrayspVertexBuffer->UnLock(...);// Then in your destructor~....(){  delete[] ter;  delete[] ter2;}

I maybe overexplained this for you, and you already understand. But what the hell

Alex Swinney

Author

Alex Swinney

Nov 16, 2004 at 5:05 PM

Quote:
Original post by Fruny
Quote:
Original post by Alex Swinney
The code between the new and delete uses the two variables to read one DX vertex buffer and write to another DX vertex buffer.

Let me draw you a picture:

The assertion checks that the block header (which contains, among other things, the number of array elements allocated, so that delete[] does the right thing), is valid. You trashed it with your DirectX data, the assertion fails.

Ahhh...See I looked for the error in google and in VS's search function, couldn't find a thing..

That picture really helps, thanks!

Alex Swinney

Author

Alex Swinney

Nov 16, 2004 at 5:06 PM

Quote:
Original post by Agony
The pointer you pass to Lock should not initially refer to allocated memory. The pointer gets set to memory already allocated by DirectX. And don't forget to call Unlock on the vertex buffer afterwards.

*** Source Snippet Removed ***

Thank you, that is one of the questions I had..

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.