Author Topic: sf::Text problem (bug?) (Read 7138 times)

replicant · « **on:** January 28, 2012, 08:35:50 pm »

I'm using the latest snapshot of SFML2. After some coding my program started crashing when I would close the rendering window, after much confusion and frustration I've narrowed it down to this.

With the code below my application will run fine until I close the rendering window (then it crashes).

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
	sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

	sf::Font font;
     if (!font.LoadFromFile("res\\font\\white_rabbit.ttf"))
         return EXIT_FAILURE;

	sf::Text text;
	text.SetString("test");
	text.SetFont(font);
	text.SetCharacterSize(50);

    //sf::Text text("Hello SFML", font, 50);

	while (window.IsOpen())
	{
		sf::Event event;
		while (window.PollEvent(event))
		{
			if (event.Type == sf::Event::Closed)
				window.Close();
		}

		window.Clear(sf::Color(0, 0, 0));

		window.Draw(text);

		window.Display();
	}

	return EXIT_SUCCESS;
}

However if I change the code to use

Code: [Select]

sf::Text text("Hello SFML", font, 50); instead. My application runs fine and doesn't crash upon closing the rendering window.

edit: Seems to work fine on linux...

Windows 7 64b
Visual Studio 2010 Express
Intel® Core™ i5 CPU M 450 @ 2.40GHz × 4
Memory: 3.7 GiB
Some ATI videocard

jone · « **Reply #1 on:** January 28, 2012, 10:09:16 pm »

I can confirm the crash on SFML2 (from git on 22.1) and Windows 7.

However, VS 2008 shows me the next line as the offender:

IIRC, I've had a similar crash when the sf::Font in sf::Text was being destroyed before the text... or something similar. Can't exactly remember.

jone · « **Reply #2 on:** January 28, 2012, 10:15:01 pm »

Not sure if this helps, but here's the call stack. Looks like this is originating from the sf::Font's destructor?

I'm not familiar with the implementation of sf::Font so I can't be of much more help.

replicant · « **Reply #3 on:** January 28, 2012, 10:55:53 pm »

Thanks for confirming it is not just me, all I know is sf::Font has reference counting.

Laurent · « **Reply #4 on:** January 28, 2012, 11:36:19 pm »

It's a known bug

jone · « **Reply #5 on:** January 30, 2012, 12:13:41 pm »

Quote from: "Laurent"

It's a known bug

After doing some reading, I think I (vaguely) understand the issue. The issues described in these threads are about the same bug, right?

http://www.sfml-dev.org/forum/viewtopic.php?t=6047
http://www.sfml-dev.org/forum/viewtopic.php?t=6130

In other words, the issue is the lines:

Code: [Select]


sf::Text text;
text.SetFont(font);

As no font is specified in the constructor, the first line instanciates the default font. This is bad because of the destruction order "issues" caused by SFML's own globals.

If I understood correctly, changing the lines to

Code: [Select]


sf::Text text("Hello SFML", font, 50);

causes the constructor of the default sf::Font not to be called, so the default font is not instaciated, and the issue is avoided.

As a side note, it might be a good idea to change the usage example of sf::Text in the SFML2 documentation, as inserting it to your own code like above can cause the issue. I mean this bit: http://sfml-dev.org/documentation/2.0/classsf_1_1Text.php#details

Laurent · « **Reply #6 on:** January 30, 2012, 12:24:18 pm »

Quote

After doing some reading, I think I (vaguely) understand the issue. The issues described in these threads are about the same bug, right?

Yep.

Quote

causes the constructor of the default sf::Font not to be called, so the default font is not instaciated, and the issue is avoided.

Correct.

Quote

As a side note, it might be a good idea to change the usage example of sf::Text in the SFML2 documentation, as inserting it to your own code like above can cause the issue. I mean this bit: http://sfml-dev.org/documentation/2.0/classsf_1_1Text.php#details

It's not a wrong usage, just a bug that will be fixed quickly after SFML 2 is released

binary1248 · « **Reply #7 on:** January 30, 2012, 12:28:02 pm »

Simply put, the default Font is a static variable (not in global scope) initialized at request and destroyed when the dll is unloaded far far after your application terminates.

You could put it this way: Because the font is the last one to leave the room. It has to turn off the lights itself. However it can't reach the light switch itself and the tall AMD driver already left before it because it didn't care much. The nVidia driver however is nicer and sticks around until everyone leaves and so doesn't cause a problem.

AMD could argue that it never said it would stick around and having static OpenGL resources is a bad idea anyway. But because there are other apps/games out there that probably do the same, I would bet that it's something particular about SFML.

jone · « **Reply #8 on:** January 30, 2012, 12:28:23 pm »

Quote from: "Laurent"

It's not a wrong usage, just a bug that will be fixed quickly after SFML 2 is released

All right, thanks for the help!

slotdev · « **Reply #9 on:** January 30, 2012, 01:11:35 pm »

Quote

It's not a wrong usage, just a bug that will be fixed quickly after SFML 2 is released

...which will be when, exactly?

Laurent · « **Reply #10 on:** January 30, 2012, 01:14:18 pm »

It's an critical bug so I'll try to fix it in SFML 2.1, but it could be complex to solve.

mateandmetal · « **Reply #11 on:** January 31, 2012, 08:08:01 am »

I´m planning to use a sf::Text object as a private member in my class.. Should I use a pointer instead? :?

Laurent · « **Reply #12 on:** January 31, 2012, 08:40:03 am »

Quote

Should I use a pointer instead?

That wouldn't change anything, except making your code more complicated to manage.

mateandmetal · « **Reply #13 on:** February 02, 2012, 04:52:20 am »

I got a SEGFAULT when closing the renderwindow

ATI Radeon HD 5670, Driver 11.9, win 7 x64, C::B/MinGW.
Hope it helps fixing the bug :roll: