MarcusAseth

Getting 0xcccccccc error

Recommended Posts

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? :P

FULL SIZE IMAGE

IbHWiGx.png

Edited by MarcusAseth

Share this post


Link to post
Share on other sites
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;

 

Share this post


Link to post
Share on other sites

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? :/

Share this post


Link to post
Share on other sites
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 :o

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.

Share this post


Link to post
Share on other sites

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 :\

Ml7Ud0b.png

Edited by MarcusAseth

Share this post


Link to post
Share on other sites

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

Edited by MarcusAseth

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
7 minutes ago, Hodgman said:

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

Got it :D

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...

Edited by MarcusAseth

Share this post


Link to post
Share on other sites

you're problem is that you are declaring a global in a header file like that. What happens is that each cpp file that includes that utils header, gets its own copy of the static variable. You end up with many, and depending how you initialize them, destructor mayhem.


Simple Test:

//util.h
#pragma once
#include <iostream>
#include <string>

static int globali = 5;
  
//main.cpp
#include "utilglobals.h"
#include "cpp2.h"

void main() {

	testGlobal();
	std::cout << "main" << (int)&globali << std::endl;

	std::cin.get();
}
//cpp2.h
#pragma once
#include "utilglobals.h"
void testGlobal();
  
//cpp2.cpp
#include "cpp2.h"
void testGlobal() {
	std::cout << "cpp2" << (int)&globali << std::endl;
}

 

Share this post


Link to post
Share on other sites

if you want to do a global you'd use a singleton of some sort:

class Singleton {
	Singleton();

	static Singleton mInstance;
public:
	static Singleton* getInstance() {
		return &mInstance;
	}

	void func();
};
//in a cpp
Singleton Singleton::mInstance;	//only exists in 1 cpp file

Singleton::getInstance()->func();

 

Edited by h8CplusplusGuru

Share this post


Link to post
Share on other sites

@h8CplusplusGuru Thanks for letting me know, I though that pragma once would ensure only one copy of the thing (so now I have no idea about what pragma once is doing, and furthermore the usage of static keyword...

This is my output:

Quote

00092390 Constructor
00092448 Constructor
00092500 Constructor
000925B8 Constructor
00092670 Constructor
00092728 Constructor
000927E0 Constructor
00092898 Constructor
00092950 Constructor


00092950 Destructor
00092950 Font was 0030FC88
00092898 Destructor
00092898 Font was 0030A7C8
000927E0 Destructor
000927E0 Font was 00305308
00092728 Destructor
00092728 Font was 002FFE48
00092670 Destructor
00092670 Font was 002FA988
000925B8 Destructor
000925B8 Font was 002F54C8
00092500 Destructor
00092500 Font was 002F0008
00092448 Destructor
00092448 Font was 002C5D68
00092390 Destructor
00092390 Font was 002C0440

so basically I was creating and destroying 9 identical Font objects, very wasteful xD 

Share this post


Link to post
Share on other sites

Your header files are managed by each cpp, not the singular program. Pragma once means it's only included once per a cpp. Static is going to be redundant at a module scope, which is always program lifetime - at other scopes, it effectively makes them module in lifetime. Static is going to be used inside classes, inside functions.

On a somewhat related topic, you want to include as few headers in other headers as possible, and include them in cpps instead. You want to have as little code other than interfaces in headers as possible, because when the header changes, the cpp users compile. Both of these tips will increase your compile speeds. (Also, on msvc, enable, /MP, which is multiprocessor compilation ).

Share this post


Link to post
Share on other sites

Historically one used the following construct via macros

#ifndef MY_HEADER_HPP

#define MY_HEADER_HPP

// some DEFINITIONS (doesn't matter for DECLARATIONS only)

#endif

to ensure at most one "actual include" in each translation unit, otherwise you would have clashes. 

All C/C++ compilers support this (It is actually the preprocessor who support this).

The following construct

#pragma once

is supported by some compilers such as MVC++ and achieves the same result with the additional benefit of not polluting your namespace of globally defined symbols (which negatively influences your preprocessor's and probably "intelligent" IDE's performance due to some larger lookup tables) with one defined symbol for each header.

Edited by matt77hias

Share this post


Link to post
Share on other sites
On 28-9-2017 at 5:20 PM, MarcusAseth said:

static keyword

The static keyword has multiple use cases including imposing internal linkage. static struct/class member variables and methods, have, however, nothing to do with internal linkage. It basically adds data and functionality to the struct/class instead of the instances of that struct/class.

Edited by matt77hias

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now