program crashes on exit

[stevend]

ok so i am basically using the example code from the tutorials.

i have made a little resource manager and all i do is load
and display a sprite.

when i press esc or the X my program crashes instead of gracefully exiting.....

when i try and debug i get this

Windows has triggered a breakpoint in 2dtile.exe.

This may be due to a corruption of the heap, which indicates a bug in 2dtile.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while 2dtile.exe has focus.

The output window may have more diagnostic information.

any one have any ideas what could be happening? ps: there is no more diagnostics information   :roll:

[stevend]

ok so if i dont load and display the sprite it doesnt crash on exit.

should i be disposing of the loaded sf::Image before i exit possibly?

[Laurent]

Can you show the code that crashes?

[stevend]

i was right, i fixed it by putting this in my resource manager deconstructor:

Code: [Select]

for (int i = 0; i < (int) _images.size(); i++)
{
delete _images.at(i);
}


and calling this before i call app->close();

Code: [Select]

this->ResourceManager.~resman();


sorry for worrying so much. this is where everything got sticky a long time ago when i tried to use sfml and now it seems im getting the hang of it faster. thanks anyways!

[Laurent]

Deleting your images is not supposed to fix this crash, you just fixed a memory leak.

You can't explicitely call a destructor, your second piece of code is wrong.

You should really show us your code so that we can find the real problem, and a clean fix

[Nexus]

deconstructor:

You mean destructor.

Code: [Select]

this->ResourceManager.~resman();

As Laurent said, don't do that. Although it's possible (and even meaningful in some cases, as counterpart to placement new), it will probably lead to undefined behaviour (UB) at you because your object is destroyed twice.

Defeating UB by creating even more UB is the worst you can do.

[stevend]

this is my resource manager.

Code: [Select]

#pragma once

#include "include.h"

namespace engine
{
class resman
{
public:

resman ()
{

};

~resman (void)
{
for (int i = 0; i < (int) _images.size(); i++)
{
delete _images.at(i);
}
};

//! Load or retreive an image from memory
sf::Image * GetImage(string filepath);

private:

//! Array of images loaded into memory
std::vector <sf::Image *> _images;

//! Array of path names of images loaded into memory
std::vector <std::string> images;


};
};

Code: [Select]

#include "include.h"

#include "factory.h"
class factory;

namespace engine
{

sf::Image * resman::GetImage(string filepath)
{
for (int i = 0; i < (int)images.size(); i++)
{
if (images.at(i).compare(filepath)==0)
return _images.at(i);

}

 // Not Found?

 sf::Image *ImgTemp = new sf::Image();
 if(ImgTemp->LoadFromFile(filepath))
 {
_images.push_back(ImgTemp);
images.push_back(filepath);
return ImgTemp;
 }
 else
 {
delete ImgTemp;
 }

 return NULL;
}


}


i put the code in the destructor so i might as well move it to a function and call it then from what you say.

i didnt see the reason why it would matter if i destroyed the resource manager class right before i call app.close();

Code: [Select]

// Close window : exit
if (Event.Type == sf::Event::Closed)
{
this->ResourceManager.~resman();

window->Close();
}

thats where i would call it[/code]

[Nexus]

i didnt see the reason why it would matter if i destroyed the resource manager class right before i call app.close();

For the third time: Calling destructors explicitly results in undefined program behaviour. As mentioned, there are exceptions, but you needn't care about them at the moment. Just don't do it.

Destructors are called automatically if you have got an object with automatic storage class ("stack") – we're not in GC languages with probabilistic destruction behaviour. Otherwise, if you allocate your class dynamically (new operator), you have to free the memory by delete. In this case, the delete operator calls the destructor.

[stevend]

yeah, thats why i said i didnt see

i didnt see the reason why it would matter

So i fixed a memory leak, and i also fixed my program crashing on exit. dont ask me why or how but me putting the contents or resman's destructor into a separate and calling it where i would call the destructor has fixed my problem. all my code is above. if you see anything im doing wrong now, please, let me know.

[Laurent]

Is your resman instance global?

[stevend]

resman is declared like

resman ResourceManager;

and is located in a singleton factory class

[Laurent]

Can you show this singleton factory class?

[Nexus]

if you see anything im doing wrong now, please, let me know.

Just don't call the destructor by hand. Why don't you believe me? Do you know what "undefined" means? It means everything can happen. Don't draw any conclusion just because your program seems to run correctly. You fixed NOTHING, you did the opposite.

Ok. Your resman instance is a member of a class, right?

Code: [Select]

resman ResourceManager;
Therefore, the destructor is automatically called in the surrounding class's destructor. Manually calling ~resman() leads to a double destruction, and the mentioned UB. Clear?

[stevend]

Code: [Select]

class factory
{
protected:
//! Pointer to the factory
static factory *dinstance;

factory ()
{

};

~factory (void) { };

public:
//! Creates or returns the factory instance
static factory *instance();

//! Initialize the game engine
void init (int width, int height, bool fullscr);

private:

//! SFML Rendering Device
sf::RenderWindow * window;

//! SFML events Device
sf::Event  Event;

//! Main Game Loop
void GameLoop ();

//! Main Event Loop
void EventLoop ();

//! Resource Manager Instance
resman ResourceManager;

//! State Manager Instance
stateman StateManager;


};

[stevend]

and im not calling it any more. as my previous posts have stated i have changed my code and no longer call the destructor. i do beleive you. lol