Jump to content
  • Advertisement
Sign in to follow this  
JackBob

Destructor crashing game?

This topic is 2630 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

so in a class I have
D3DMATERIAL9* mmaterial;

LPDIRECT3DTEXTURE9* ttexture;

as global variables that are used for loading in meshs and what not.

Whenever I close the program I get memory leaks from them as they are not being destroyed.
So simple enough I just make a destructor and in it I put
delete[] mmaterial;
delete[] ttexture;

inside of it
When I start up my game it crashes the game and visual studio. And I'm not particularly sure why...
my destructor looks like this
Ship::~Ship()
{
delete[] mmaterial;
delete[] ttexture;
}

Any insight or links to other articles would be helpful =)
or atleast what to search for since it seems apparently I can't find anything
Thanks

Share this post


Link to post
Share on other sites
Advertisement
I'd need more information on the crash. Does it pop an error message ? But on the top of my head I would say try using the Release() method for both objects instead of deleting them yourself. Of course you have to be sure they contain valid data before using the Release method.

Share this post


Link to post
Share on other sites

delete[] mmaterial;
delete[] ttexture;


Why this? Your data members are declared as:
D3DMATERIAL9* mmaterial;
LPDIRECT3DTEXTURE9* ttexture;


You do not have an array of them, just a pointer to them. Try to remove the brackets [ ].

Share this post


Link to post
Share on other sites

You do not have an array of them, just a pointer to them. Try to remove the brackets [ ].

In C++ a pointer to a single element and a pointer to an array of elements have the same type. You can't know without seeing how it's used which a pointer is pointing to.

Share this post


Link to post
Share on other sites
You do not have an array of them, just a pointer to them. Try to remove the brackets [ ].[/quote]

I agree for the first one (D3DMATERIAL9). However LPDIRECT3DTEXTURE9 is a definition of a pointer to a DIRECT3DTEXTURE9 structure. However I'm a bit rusty with C++ and I'm not sure how the delete operator works with typedefs

EDIT : Well, SiCrane must know better than me ;)

Share this post


Link to post
Share on other sites
you cant delete a texture, its governed by the graphics adapter.
Use

delete[] mmaterial; (if its an array)
ttexture->Release();

instead.

or even better:

if(mmaterial != NULL)
delete[] mmaterial;

if(ttexture != NULL)
ttexture->Release();

with that, youll also have to set the pointers to null in the ctor:

Ship::Ship()
{
mmaterial = NULL;
ttexture = NULL;
}

with that, if something happens and the stuff never gets allocated, it wont crash since the pointer has not changed from NULL.

Share this post


Link to post
Share on other sites

[quote name='0x3a' timestamp='1317068789' post='4866204']
You do not have an array of them, just a pointer to them. Try to remove the brackets [ ].

In C++ a pointer to a single element and a pointer to an array of elements have the same type. You can't know without seeing how it's used which a pointer is pointing to.
[/quote]

True, but seeing he had a crash and his data is, hopefully, correct it could be the case.

Share this post


Link to post
Share on other sites
In the case of some compilers sticking the length of an array allocated with new just before the returned pointer, wouldn't attempting to read before the block allocated for a single object cause an access violation if one uses the wrong delete?

Share this post


Link to post
Share on other sites

However I'm a bit rusty with C++ and I'm not sure how the delete operator works with typedefs

The delete operator doesn't care about typedefs, it just looks at the actual type. In the case of an LPDIRECT3DTEXTURE9 *, that would be a Direct3DTexture9 **. This could either be a pointer to a Direct3DTexture9 pointer or a pointer to an array of pointers.


True, but seeing he had a crash and his data is, hopefully, correct it could be the case.

There is a difference between saying "this could be the cause of your crash" and "this is the cause of your crash". Please observe this distinction when making future posts.


In the case of some compilers sticking the length of an array allocated with new just before the returned pointer, wouldn't attempting to read before the block allocated for a single object cause an access violation if one uses the wrong delete?

In theory, it could. Using the wrong delete or delete [] has undefined behavior, which means anything can happen, including an access violation on that read. However, it's not guaranteed. For an access violation to occur on that read, the memory in that location would need to lack read permission, and, in practice, most memory allocators place other bookkeeping structures in front of allocated blocks, so that particular read rarely causes an access violation by itself. Acting on the information in the memory, on the other hand, has much better chances of bringing down the program somehow. If the type lacks a destructor, then it's entirely possible for using delete [] instead of delete to deallocate the memory successfully. Undefined behavior means anything can happen, up to and including "working".

Share this post


Link to post
Share on other sites
Hidden
Ok first off Thanks for all the replies. I figure I should post all the code so you guys can have a better idea of what is happening
and second off I deeply apologize for my code pasted into here like this. The code tags and the source tags just leave my code with a bunch of jibberish added on for no reason


Ship::Ship(LPCTSTR nameT, LPDIRECT3DDEVICE9 dDevice)
{

d3Device = dDevice;
name = nameT;
LPD3DXBUFFER bufShipMaterial;

D3DXLoadMeshFromX(name, // load this file
D3DXMESH_SYSTEMMEM, // load the mesh into system memory
d3Device, // the Direct3D Device
NULL, // we aren't using adjacency
&bufShipMaterial, // put the materials here
NULL, // we aren't using effect instances
&NumMaterials, // the number of materials in this model
&Mesh); // put the mesh here

// retrieve the pointer to the buffer containing the material information
D3DXMATERIAL* tempMaterials = (D3DXMATERIAL*)bufShipMaterial->GetBufferPointer();

// create a new material buffer for each material in the mesh
mmaterial = new D3DMATERIAL9[NumMaterials];
ttexture = new LPDIRECT3DTEXTURE9[NumMaterials];

for(DWORD i = 0; i < NumMaterials; i++) // for each material...
{
mmaterial = tempMaterials.MatD3D; // get the material info
mmaterial.Ambient = mmaterial.Diffuse; // make ambient the same as diffuse
// if there is a texture to load, load it
if(FAILED(D3DXCreateTextureFromFileA(d3Device,
tempMaterials.pTextureFilename,
&ttexture)))
ttexture = NULL; // if there is no texture, set the texture to NULL
}
}

Now that is the inside of my constructor for my Ship class. All it does really is just load in the mesh I want for whichever "Ship"
I realize some is messy and I intend on cleaning on all my code once I fix all my memory leaks.

and my destructor

Ship::~Ship()

{

[color="#0000ff"][color="#0000ff"]for(DWORD i = 0; i < NumMaterials; i++)

{

ttexture->Release();

}



[color="#0000ff"][color="#0000ff"]delete[] ttexture;

[color="#0000ff"][color="#0000ff"]delete[] mmaterial;

}

and after reading through your comments and what not I tried using just delete vs delete[]. In my default constructor I made both variables null just in case

Pretty much what happens is when I run game in visual studio as its loading up it freezes and freezes up visual studio to the point where I have to end process everytime.
So i'm assuming there is a memory leak that its just not liking?


Ship::Ship()
{
mmaterial = NULL;
ttexture = NULL;
}




Share this post


Link to post
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!