Closing window causes access violation

[Beta_Ravener]

My 2 programs using SFML 2.0 have both some strange glitch, that doesn't affect them but it's annoying. I'm creating sf::Window and sf::Render window in first and sf::Window in second and both programs are using also console window from sfml-main. When those windows appers on screen they behave correct and everything, but closing them through X in right up corner cause the created windows disappear (I think they close correctly), but that console window stays stuck for 3-4 seconds and then it crash. Note that when I close window my programs end(because of loop that uses sf::Window::IsOpened()). I get access violation, but it's not in my code and gets thrown after my main() function returns and formally ends program. The strange thing is, that when program is closed by clicking X in corner of console window everything closes correctly and no error appears.

I'm still not sure if it's bug in my code or SFML, because I was unable to jump from my code to SFML files. It can be still that I forgot to do something with resource inside my code, but I checked it few times and made destructors for almost every class cleaning those resources before program ends. Didn't help though, so I deleted those destructors for not to make more mess than there already is.

And sorry if there's topic like this, I couldn't find anything helpful (other than some topic about SFML using globals bacause of some ATI driver bug.. so maybe it'd help to say that I'm using ATI).

[Beta_Ravener]

Ok I got something.. though I still can't jump to sfml source to track it down, I just noticed that upon exit in debug mode I got this line in console: "An internal OpenGL call failed in Image.cpp (90) : GL_INVALID_OPERATION, the specified operation is not allowed in the current state".

Also in debug mode, visual studio can look into disassmbly and tell me some info. Well when my main function returns, it's Main thread[5092] and stack frame is Waves.exe!_tmainCRTStartup(and some more info), but it stays here for about 6 steps. Then it executes: "0141A10F  call        dword ptr [__imp__exit (1430B04h)] ". It gets through msvcr90d.dll, kernel32.dll, ntdll.dll, and maybe others.. it's probably cleaning this debug info. But what's interesting, it finally gets to that line causing troubles: "69092994  mov         edi,dword ptr [eax+8] " in Main Thread[5092] and stack frame is "atioglxx.dll!69092994()" .

Hope this helps somehow

[sbroadfoot90]

I'm still not sure if it's bug in my code or SFML

care to show your code?

[Beta_Ravener]

care to show your code?

Sure.. in fact while trying to get together some code to post here, I've found exact place where this happens. It happens when I call single function in my first program with 2 windows (the second one is out because it had the very same error but it was because of one vector).

This is the code for rendering second window, which is something like child to first, because it closes when the first one closes.

Code: [Select]

void SettingsUI::Render(){
window.SetActive();
window.Clear(sf::Color(0,0,0));
sf::Text text;
text.SetCharacterSize(20);
text.SetColor(sf::Color(30, 255, 30));
unsigned int i;
for(i = 0; i < menuSize; i++){
text.SetString(menuText[i]);
text.SetPosition(10.f, i*25.f+10.f);
window.Draw(text);
}
text.SetString("Input: " + input);
text.SetPosition(10.f, i*25.f+30.f);
window.Draw(text);

window.Display();
window.SetActive(false);
}

If I won't call this from my main function, the program ends without error. Playing with those commands I found that the only line causing trouble is:

Code: [Select]

window.Draw(text); If you comment both of them away, text is not displayed but no error occurs on closing.

It may help to say that I initialize window this way:

Code: [Select]

window.Create(sf::VideoMode(500, 300, 32), "Settings", sf::Style::Titlebar);
and close like this:

Code: [Select]

void SettingsUI::Close(){
window.Close();
menuText.clear();
waveEngine = 0;
}

Also note that

Code: [Select]

std::vector<sf::String> menuText;
sf::String input;

[Laurent]

It's probably the known bug of the default font which causes a crash at global exit.

[Beta_Ravener]

Then it should be true, that default font is loaded only if no other font is bind to sf::Text while calling sf::RenderWindow::Draw ? If so, would loading my own font to sf::Font and using this one prevent the crash?

And why closing console window doesn't result it crash? The console window, however, stays stuck for some time, and at last the programs ends returning exit code -1073741510 (but at the end of main I return 0).

[Laurent]

Then it should be true, that default font is loaded only if no other font is bind to sf::Text while calling sf::RenderWindow::Draw ? If so, would loading my own font to sf::Font and using this one prevent the crash?

To prevent the crash, the default font must never be instanciated, so you have to pass your own font to the constructor of all your sf::Text instances.
Doing it with the SetFont function is already too late.

And why closing console window doesn't result it crash?

Closing the console terminates the program in a very ugly way -- nothing gets destructed properly. So no "crash", but memory leaks etc.

[Beta_Ravener]

Closing the console terminates the program in a very ugly way -- nothing gets destructed properly. So no "crash", but memory leaks etc.

That's quite disturbing as I'm planning to use console in final release.. when we are at it, is there any way to disable all the options to close console?

[Laurent]

That's quite disturbing as I'm planning to use console in final release..

That's fine, just don't close it directly.

when we are at it, is there any way to disable all the options to close console?

I don't think that Windows allows this.

[Beta_Ravener]

Thanks for the help.

And one more thing, though this might be already known. I didn't want to have to include font with my program and as the built-in arial was pretty good, I just did:

Code: [Select]

sf::Font font = sf::Font::GetDefaultFont();
and this one I passed into sf::Text constructor. The result is same as before, but no crash anymore. As I read in that other thread, you got problems with those global variables, that can't be initialized before entering main function. Maybe you could have a class inside SFML that groups all the globals and something like sf::Init() that would user call from body of his main? It's the very same as glewInit() I need to call before I can use many of openGL calls, and there probably isn't better way to do this.

[Laurent]

The result is same as before, but no crash anymore.

That's... strange :?

As I read in that other thread, you got problems with those global variables, that can't be initialized before entering main function. Maybe you could have a class inside SFML that groups all the globals and something like sf::Init() that would user call from body of his main? It's the very same as glewInit() I need to call before I can use many of openGL calls, and there probably isn't better way to do this.

It's a little bit more complicated

[slotdev]

Laurent

I really need a fix for this text bug very soon. I can guarantee that I don't need the default font, so can I comment out some code in the libraries to stop the default font being instanciated? If so, can you tell me which lines?

I don't care what I have to do to fix this, but I need to do it now!

[Laurent]

You can comment every call to Font::GetDefaultFont (should occur in sf::Text constructors only), and assign NULL instead.

[slotdev]

So what should the Text.hpp say?

Code: [Select]


explicit Text(const String& string, const Font& font = Font::GetDefaultFont(), unsigned int characterSize = 30);

I assume it needs to call a function to just return a NULL sf::Font ??

[Laurent]

Just remove the default argument. If you really need to construct sf::Text instances from just a string, add a new constructor:

Code: [Select]

Text(const String& string);