Author Topic: GetDefaultFont causes crash on exit (Read 5599 times)

Iteem · « **on:** May 01, 2011, 05:04:14 pm »

Using sf::Font::GetDefaultFont (SFML2) causes a segmentation fault when closeing the program. If I only use fonts loaded from a file or whatever it works like intended.

Here is the backtrace:

Code: [Select]

#0 019298AD	atioglxx!DrvRealizeLayerPalette() (C:\WINDOWS\system32\atioglxx.dll:??)
#1 00000000	0x0467a45c in ??() (??:??)
#2 0197241E	atioglxx!atiPPHSN() (C:\WINDOWS\system32\atioglxx.dll:??)
#3 00000000	0x0467a200 in ??() (??:??)
#4 00000000	0x0022fe40 in ??() (??:??)
#5 022062D5	atioglxx!DrvValidateVersion() (C:\WINDOWS\system32\atioglxx.dll:??)
#6 00000000	0xffffffff in ??() (??:??)
#7 5F0E9926	wglSwapLayerBuffers() (C:\WINDOWS\system32\opengl32.dll:??)
#8 6E185583	~WglContext(this=0x6a4f50) (E:\Programmierung\SFML2\SFML\src\SFML\Window\Win32\WglContext.cpp:118)
#9 6E181A5D	sf::priv::GlContext::Cleanup() (E:\Programmierung\SFML2\SFML\src\SFML\Window\GlContext.cpp:127)
#10 6E18235F	~GlResource(this=0x598d934) (E:\Programmierung\SFML2\SFML\src\SFML\Window\GlResource.cpp:79)
#11 68EC48C1	~Image(this=0x598d934) (E:\Programmierung\SFML2\SFML\src\SFML\Graphics\Image.cpp:92)
#12 68F7631B	~Page(this=0x598d91c) (E:/Programmierung/SFML2/SFML/include/SFML/Graphics/Font.hpp:222)
#13 68FC0ECC	~pair(this=0x598d918) (d:/programme/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_pair.h:68)
#14 68F77879	__gnu_cxx::new_allocator<std::pair<unsigned int const, sf::Font::Page> >::destroy(this=0x22fc03, __p=0x598d918) (d:/programme/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/include/c++/ext/new_allocator.h:115)
#15 68FC6200	std::_Rb_tree<unsigned int, std::pair<unsigned int const, sf::Font::Page>, std::_Select1st<std::pair<unsigned int const, sf::Font::Page> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, sf::Font::Page> > >::_M_destroy_node(this=0x69056088, __p=0x598d908) (d:/programme/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_tree.h:383)
#16 68FC6D9A	std::_Rb_tree<unsigned int, std::pair<unsigned int const, sf::Font::Page>, std::_Select1st<std::pair<unsigned int const, sf::Font::Page> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, sf::Font::Page> > >::_M_erase(this=0x69056088, __x=0x598d908) (d:/programme/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_tree.h:972)
#17 68FC6AD9	std::_Rb_tree<unsigned int, std::pair<unsigned int const, sf::Font::Page>, std::_Select1st<std::pair<unsigned int const, sf::Font::Page> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, sf::Font::Page> > >::clear(this=0x69056088) (d:/programme/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_tree.h:726)
#18 68FC09B1	std::map<unsigned int, sf::Font::Page, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, sf::Font::Page> > >::clear(this=0x69056088) (d:/programme/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_map.h:626)
#19 68EC2CFD	sf::Font::Cleanup(this=0x69056060) (E:\Programmierung\SFML2\SFML\src\SFML\Graphics\Font.cpp:297)
#20 68EC239F	~Font(this=0x69056060) (E:\Programmierung\SFML2\SFML\src\SFML\Graphics\Font.cpp:69)
#21 68EC2B59	__tcf_0() (E:\Programmierung\SFML2\SFML\src\SFML\Graphics\Font.cpp:249)
#22 68EC1086	__dll_exit() (C:\WINDOWS\system32\sfml-graphics-d-2.dll:??)
#23 68EC1106	DllMainCRTStartup@12() (C:\WINDOWS\system32\sfml-graphics-d-2.dll:??)
#24 7C91118A	ntdll!LdrSetAppCompatDllRedirectionCallback() (C:\WINDOWS\system32\ntdll.dll:??)
#25 00000000	0x68ec0000 in ??() (??:??)
#26 00000000	0x00000000 in ??() (??:??)

I'm using SFML2 and WinXP. My video card is a Radeon X1650, that might be relevant

Mr. X · « **Reply #1 on:** May 01, 2011, 05:12:17 pm »

Using a Radeon HD 4850 on Windows 7 I get the same issue.

Visual Studio says, the crash happens in GlContext.cpp in function GlContext::Cleanup, first line. It seems like the pointer sharedContext is invalid but not zero.

Laurent · « **Reply #2 on:** May 01, 2011, 05:58:34 pm »

This is a known bug.

There are two workarounds:
- link statically
- don't use the default font

Mr. X · « **Reply #3 on:** May 01, 2011, 06:38:26 pm »

I thought, it was fixed since SFML 1, and I have not noticed it for a long time...

Laurent · « **Reply #4 on:** May 01, 2011, 07:51:27 pm »

It was fixed but it reappeared

Tank · « **Reply #5 on:** January 22, 2012, 01:56:12 pm »

Is there a way to give the developer control of the context destruction? I don't see "link statically" and "don't use default font" to be a valuable solution.

Laurent · « **Reply #6 on:** January 22, 2012, 03:54:23 pm »

No, but to solve the problem it's the lifetime of the default font that you must control. And... well, it is possible of course but I don't see any clean way of allowing it.

Tank · « **Reply #7 on:** January 22, 2012, 06:19:33 pm »

What unclean ways do you see?

Edit: What about a default font building func instead of returning a static variable? Like "sf::Font sf::Font::BuildDefaultFont()"?

Laurent · « **Reply #8 on:** January 22, 2012, 06:46:00 pm »

Quote

Edit: What about a default font building func instead of returning a static variable? Like "sf::Font sf::Font::BuildDefaultFont()"?

What's cool with the default font is that you can create sf::Text instances that work out of the box.
But yeah, that would probably be the best solution.

Tex Killer · « **Reply #9 on:** January 22, 2012, 07:19:12 pm »

You could also check on the GetDefaultFont if the default font was already created or not, creating it on the first call and returning it after that.

Tank · « **Reply #10 on:** January 23, 2012, 05:25:35 pm »

You didn't check the source code, did you?

Tex Killer · « **Reply #11 on:** January 23, 2012, 10:03:49 pm »

kkk, sorry
Even by re-reading the posts I see that what I've said doesn't solve shit, neither make sense.