sf::Font does not properly free freetype glyphs in the destructor.

[tylerreisinger]

It appears the glyph cache inside of sf::Font is never properly freed, leaking all used glyphs after the Font is destroyed.

If fonts are repeatedly created and destroyed during a program, the leaked memory can become quite large.

Below is a valgrind memcheck output from a small project I noticed the problem in. Notice that it leaks 14 blocks, which is exactly how many distinct glyphs I use (numbers 0-9, '.' and 'fps'). For unicode text and larger point sizes, each font could easily leak into the 100s of KBs of memory. The sf::Font object is properly destroyed in this example before termination.

==30433== 9,188 (1,120 direct, 8,068 indirect) bytes in 14 blocks are definitely lost in loss record 83 of 85
==30433==    at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30433==    by 0x7882EEC: ??? (in /usr/lib/libfreetype.so.6.15.0)
==30433==    by 0x7882F36: ??? (in /usr/lib/libfreetype.so.6.15.0)
==30433==    by 0x788A368: ??? (in /usr/lib/libfreetype.so.6.15.0)
==30433==    by 0x788A6A9: FT_Get_Glyph (in /usr/lib/libfreetype.so.6.15.0)
==30433==    by 0x528165A: sf::Font::loadGlyph(unsigned int, unsigned int, bool, float) const (in /usr/lib/libsfml-graphics.so.2.4.2)
==30433==    by 0x5281CEB: sf::Font::getGlyph(unsigned int, unsigned int, bool, float) const (in /usr/lib/libsfml-graphics.so.2.4.2)
==30433==    by 0x52B222B: sf::Text::ensureGeometryUpdate() const (in /usr/lib/libsfml-graphics.so.2.4.2)
==30433==    by 0x52B277B: sf::Text::draw(sf::RenderTarget&, sf::RenderStates) const (in /usr/lib/libsfml-graphics.so.2.4.2)
==30433==    by 0x52A48A8: sf::RenderTarget::draw(sf::Drawable const&, sf::RenderStates const&) (in /usr/lib/libsfml-graphics.so.2.4.2)
==30433==    by 0x10ED1D: Game::draw_fps(GameTime const&) (Game.cpp:137)
==30433==    by 0x10E627: Game::draw(GameTime const&) (Game.cpp:123)

[LaurentGomila]

Are you using the public 2.4.2 release of SFML, or the master revision from git?

[tylerreisinger]

This was on 2.4.2.

[eXpl0it3r]

This has already been fixed in #1216. 😉

If possible, make sure to test against master first before raising an issue.