I don't know why this is happening, in the image below you can see my current situation.

Basically I have an Utility.h header which contains wathever random stuff I think is useful at the time but don't yet deserves it's own separate file, so inside of it I've put a BaseFont class and defined it in place since I am not sure it will stay into Utility.h for long (Font is an alias for BaseFont because I wanted the internal variable name for the font to be Font, and that would collide with the class name, so that's why I have it setup like this) and right below this class, still in the header, I have a global object constructed from it so that I can use it everywhere for debug since pretty much all my .cpp #include "Utility.h". Now when I close the game I get an error that says "Breakout.exe stop working" and I tracked it down to the BaseFont destructor. On the right of the image you can see the local variable situation at that break point, which doesn't looks good...

I have some assumptions regarding the cause but I am not quite sure, can you tell me what its going wrong exactly?

FULL SIZE IMAGE

Your class doesn't comply with the rule of three, which means that if anyone copies it, you'll end up with a double deletion bug in the destructor, so that could be it.

2 minutes ago, Hodgman said:

Your class doesn't comply with the rule of three, which means that if anyone copies it, you'll end up with a double deletion bug in the destructor, so that could be it.

Added the code below, still in the same situation, must be something else

	BaseFont(const BaseFont&) = delete;
	BaseFont& operator=(const BaseFont&) = delete;
	BaseFont(BaseFont&&) = delete;
	BaseFont& operator=(BaseFont&&) = delete;

More informations:

App::~App()
{
	if (Window) { SDL_DestroyWindow(Window); }
	if (Renderer) { SDL_DestroyRenderer(Renderer); }
	for (auto& elem : Textures)
	{ SDL_DestroyTexture(elem.second); }

	if (TTF_WasInit()) { TTF_Quit(); };
	SDL_Quit();
}

I think the "global static" Font Arial lifetime has to do with the problem, since I am guessing the object is probably still around after TTF_Quit() is called (which happen after main() returns basically.

But still, I tested by removing the TTF_Quit() and it improves since I don't get the "Breakout.exe stop working" anymore, but according to the debbugger when we hit that breakpoint in the image in the first post, the situation is still the same, the memory of "this" being 0xcccccccc... any idea why is that?

8 minutes ago, MarcusAseth said:

the memory of "this" being 0xcccccccc... any idea why is that?

0xcc is microsoft's debug mode marker for uninitialized stack memory. You'll notice others over time too -- 0xcd is uninitialized heap memory, 0xdd/0xfeee is free'ed memory, 0xfd is guard regions to check for overruns... So this is an indication that 'this' is pointing to a region of the stack that's never been used

What's the call-stack when the crash happens? How are you instantiating the BaseFont class?

[edit] Taking another look at your code, a side issue is that you never initialize the 'Font' member, but read from it before ever writing to it (via "if (Font)"). This is extremely dangerous and is only working due to luck at the moment.

I apologize, actually it appears that if I step forward into the code, the 0xcccccccc turns itself into a reasonable address when it hit the problem (as shown in the image below), and the problem I think it was calling a TTF function after TTF_Quit().

It's just strange that didn't show me the proper "this" address at the breakpoint and even after stepping forward twice, only changed into it when it hits the error, is this something that happens debugging static variables?!

Anyway I still have the problem of  TTF_Quit() being called before the font are closed...how should I do in order to have that font global? I should like wrap it into a "global static FontManager" in which I register and request fonts and it takes care of freeying all the fonts before calling TTF_Quit()? Seems the only way I think :\

Why would a Font not be freed before TTF_Quit is called? Isn't that happening right at the end of your program?

The Font is a static object created in an included header, the App object is created inside of main(), I think it has to do with it.

I placed 2 breakpoints, one on App destructor and one on the Font destructor, App's destructor get fired first :\

So that's why I thought they should be wrapped together in another class "FontManager", so that I can keep the global object behaviour for the Font and correctly order the cleanup inside of a single destructor

Don't create code that runs before/after main. That means don't create global objects with non-trivial constructors/destructors. It only causes headaches.

If you really need a global font (hint: you don't, but whatever), then create the font object itself inside main, and create a global pointer to it.

7 minutes ago, Hodgman said:

If you really need a global font (hint: you don't, but whatever)

Got it

I should probably pack it in a vector<Font> into the App class . Is ok to have it on the stack though? Or should I use unique_ptr for those as well? Font sounds like a lightweight thing, but I don't want to make assumptions...