[SOLVED] Weird error in sf::Font initialization

[Anrock]

Hi, recently my game begin segfaulting with this backtrace

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
memset () at ../sysdeps/x86_64/memset.S:78
78 ../sysdeps/x86_64/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../sysdeps/x86_64/memset.S:78
#1  0x00007ffff7994711 in sf::Font::loadGlyph(unsigned int, unsigned int, bool) const () from /usr/local/lib64/libsfml-graphics.so.2
#2  0x00007ffff7994e69 in sf::Font::getGlyph(unsigned int, unsigned int, bool) const () from /usr/local/lib64/libsfml-graphics.so.2
#3  0x00007ffff79b7533 in sf::Text::updateGeometry() () from /usr/local/lib64/libsfml-graphics.so.2
#4  0x00007ffff79b7e83 in sf::Text::Text(sf::String const&, sf::Font const&, unsigned int) () from /usr/local/lib64/libsfml-graphics.so.2
#5  0x0000000000506286 in Computers::Software::Programs::UpperPanel::UpperPanel (this=0x79ac50, os=...) at /home/anrock/Documents/cprl/src/Computers/Software/Programs/UpperPanel.cpp:10
#6  0x00000000005029e4 in Computers::Software::Programs::ProgramFactory::spawn (os=..., id="UpperPanel") at /home/anrock/Documents/cprl/src/Computers/Software/Programs/ProgramFactory.cpp:25
#7  0x00000000004fdf63 in Computers::Software::OperatingSystem::start (this=0x7942a0) at /home/anrock/Documents/cprl/src/Computers/Software/OperatingSystem.cpp:98
#8  0x00000000004f7f51 in Computers::Computer::turnOn (this=0x7fffffffb2a0) at /home/anrock/Documents/cprl/src/Computers/Computer.cpp:44
#9  0x00000000004ec624 in ____C_A_T_C_H____T_E_S_T____14 () at /home/anrock/Documents/cprl/Tests/TestCp.cpp:23
#10 0x00000000004b3396 in Catch::FreeFunctionTestCase::invoke (this=0x74e770) at /home/anrock/Documents/cprl/Tests/catch.hpp:5414
#11 0x00000000004a3a25 in Catch::TestCase::invoke (this=0x74a7d0) at /home/anrock/Documents/cprl/Tests/catch.hpp:6282
#12 0x00000000004b135d in Catch::RunContext::runCurrentTest (this=0x7fffffffddf0, redirectedCout="", redirectedCerr="") at /home/anrock/Documents/cprl/Tests/catch.hpp:5027
#13 0x00000000004b033d in Catch::RunContext::runTest (this=0x7fffffffddf0, testCase=...) at /home/anrock/Documents/cprl/Tests/catch.hpp:4873
#14 0x00000000004b1e2b in Catch::Runner::runTestsForGroup (this=0x7fffffffe010, context=..., filterGroup=...) at /home/anrock/Documents/cprl/Tests/catch.hpp:5164
#15 0x00000000004b1b23 in Catch::Runner::runTests (this=0x7fffffffe010) at /home/anrock/Documents/cprl/Tests/catch.hpp:5145
#16 0x00000000004b2ad0 in Catch::Session::run (this=0x7fffffffe300) at /home/anrock/Documents/cprl/Tests/catch.hpp:5287
#17 0x00000000004b299e in Catch::Session::run (this=0x7fffffffe300, argc=1, argv=0x7fffffffe4c8) at /home/anrock/Documents/cprl/Tests/catch.hpp:5270
#18 0x00000000004a71ba in main (argc=1, argv=0x7fffffffe4c8) at /home/anrock/Documents/cprl/Tests/catch.hpp:8247
Font loaded like this:

        if (!SystemFont.loadFromFile("Resources/Fonts/Terminus.ttf"))
                std::cerr << "Can't load font" << std::endl;
 

No error reported

Then sf::Text field is initialized with this font in another class like this:

username(OS.getUsername(), OS.getFont(), 14)

getUsername() returns std::strings and getFont() returns reference to loaded font.

Now about weirdness i've found.
GDB's "p SystemFont" before SystemFont is initialized looks like this:

SystemFont = {m_library = 0x0, m_face = 0x0, m_streamRec = 0x0, m_refCount = 0x0, m_pages = std::map with 0 elements, m_pixelBuffer = std::vector of length 0, capacity 0}

and after call to loadFromFile:

SystemFont = {m_library = 0x794680, m_face = 0x799cc0, m_streamRec = 0x0, m_refCount = 0x790cd0, m_pages = std::map with 7947120 elements<error reading variable: Cannot access memory at address 0x18>,
  m_pixelBuffer = std::vector of length 0, capacity 0}

I've tried to make minimal code:

#include <SFML/Graphics.hpp>
#include <iostream>

int main(int argc, char* argv[])
{
        sf::Font font;
        if (!font.loadFromFile("Resources/Fonts/Terminus.ttf"))
                std::cerr << "Font not loaded";
        return 0;
}

and look at font after initialization... and it was initialized ok!

font = {m_library = 0x604db0, m_face = 0x6030f0, m_streamRec = 0x0, m_refCount = 0x604a40, m_pages = std::map with 0 elements, m_pixelBuffer = std::vector of length 0, capacity 0}

Also about weirdness: i didn't alternate font loading and related code for a long while. It just suddenly stopped working.

[Anrock]

Erm... Should i report a bug?

[Laurent]

Nop. Before reporting a bug, you must be able to reproduce it in a complete and minimal code that everybody can test.

[Nexus]

To understand in detail what Laurent means, here's the link to the forum rules:
http://en.sfml-dev.org/forums/index.php?topic=5559

Note the section about minimal complete examples.

[Anrock]

Well then, does anybody got an idea why sf::Font initializes itself with m_pages being std::map with insane number of elements somewhere in 0x000000018?

[Nexus]

No, of course not... And we already answered that.

You're probably messing up something else (undefined behavior, or linked wrong libraries). That's exactly why you should provide a minimal example. Please just do it, everything else is a waste of time.

[Anrock]

I can't provide minimal example, unfortunately. As i said earlier - same construction works as minimal example, but doesn't work ingame. I'm asking for some clues where to look for a problem. I don't know where to look exactly because font already malformed after initialization and my code doesn't use multithreading.
(I checked library, it's the same sfml that cmake was founding before crash appeared, now i'm emerging it with debug flags to look inside)

UPD. I'm confused. Through git bisecting i found that that crash present in very first commit where line with font loading is added.

[Laurent]

Since you have one code that works, and one that doesn't, it should be easy to find what's wrong. Take the code that works, and add parts of the one that doesn't one by one until it crashes. Or the other way round: remove things from the big code until it stops crashing.

[Anrock]

Found the thing. SFML libraries was wrong, so Nexus was right after all.
Cmake in game project was linking against sfml libs from /usr/local/ and in minimal examples i was linking with -lsfml-smth which was linking against libs from /usr/lib64. I only spotted difference by diffing ldd output for good and bad executables.

I'm using FindSFML.cmake module copypasted somewhere from internet and /usr/include and /usr/lib is not even in search path there. Though i don't know how it managed to find libs in /usr/local (which was never there, as emerge installs libsfml into proper /usr/{include,lib}. But whatever.

Is there official cmake module for finding sfml?

p.s. sorry for being an ass.

[Nexus]

Is there official cmake module for finding sfml?

Yes, there is one in the SDK, in cmake/Modules/FindSFML.cmake.

p.s. sorry for being an ass.

Don't worry, just keep in mind that we're usually giving certain advice for a reason. This reason is that dozens of people have had the same problem with the same symptoms before, so it's standing to reason to check them first

Anyway, good that you found the problem!

[Anrock]

dafuq. It appears i already was using official cmake module. It links against libs in /usr/local, which symlinks to my /usr/lib and /usr/includes, so libs and includes themselves are ok.

A bit more experimenting and i managed to make minimal example (attached). Example doesn't crash like my game, but font is corrupted. And i don't know if it would reproduce outside of my machine.

So:

1. unpack
2. mkdir build
3. cd build
4. cmake ..
5. make
6. break on line 7 of Test executable and inspect font variable
7. ???
8. m_pages = std::map with 140737488347824 elements<error reading variable: Cannot access memory at address 0x18>
 

Now do:

1. rm -rf * (inside build dir)
2. g++ -g ../test.cpp -lsfml-system -lsfml-graphics
3. break on line 7 of a.out and inspect font variable
4. ???
5. m_pages = std::map with 0 elements
 

ldd output of bad executable:

ldd Test
        linux-vdso.so.1 (0x00007fffdcc00000)
        libsfml-system.so.2 => /usr/local/lib64/libsfml-system.so.2 (0x00007fdd06d90000)
        libsfml-graphics.so.2 => /usr/local/lib64/libsfml-graphics.so.2 (0x00007fdd06b48000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007fdd06840000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fdd06548000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007fdd06330000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fdd05f88000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdd05d68000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fdd05b60000)
        libsfml-window.so.2 => /usr/lib64/libsfml-window.so.2 (0x00007fdd05948000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fdd056a0000)
        libGLEW.so.1.10 => /usr/lib64/libGLEW.so.1.10 (0x00007fdd05410000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fdd051b8000)
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fdd04e68000)
        libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007fdd04c60000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007fdd04a40000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fdd04708000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fdd044f0000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007fdd042e0000)
        libudev.so.1 => /lib64/libudev.so.1 (0x00007fdd07178000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdd06fa0000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fdd040c8000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fdd03eb8000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fdd03c80000)
        libnvidia-tls.so.340.17 => /usr/lib64/libnvidia-tls.so.340.17 (0x00007fdd03a78000)
        libnvidia-glcore.so.340.17 => /usr/lib64/libnvidia-glcore.so.340.17 (0x00007fdd00e60000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fdd00c58000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fdd00a50000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fdd00830000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fdd00620000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fdd00418000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fdd00210000)
 

Good:

        linux-vdso.so.1 (0x00007fff75ff8000)
        libsfml-system.so.2 => /usr/lib64/libsfml-system.so.2 (0x00007f6adff08000)
        libsfml-graphics.so.2 => /usr/lib64/libsfml-graphics.so.2 (0x00007f6adfcd0000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f6adf9c8000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6adf6d0000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f6adf4b8000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6adf110000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6adeef0000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f6adece8000)
        libsfml-window.so.2 => /usr/lib64/libsfml-window.so.2 (0x00007f6adead0000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f6ade828000)
        libGLEW.so.1.10 => /usr/lib64/libGLEW.so.1.10 (0x00007f6ade598000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007f6ade340000)
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f6addff0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6ae0118000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f6addcb8000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f6addaa8000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f6add890000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f6add680000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6add448000)
        libnvidia-tls.so.340.17 => /usr/lib64/libnvidia-tls.so.340.17 (0x00007f6add240000)
        libnvidia-glcore.so.340.17 => /usr/lib64/libnvidia-glcore.so.340.17 (0x00007f6ada628000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f6ada410000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f6ada208000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f6ad9fe8000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f6ad9dd8000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f6ad9bd0000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f6ad99c8000)

I guess there is something with cmake

[Nexus]

If it's truly minimal, can you post the code here? Most people don't want to download and extract an archive just to look at the code. If it's too long to post, then shorten it until it fits the link in my first post. I really hope it's not necessary to repeat it...

By the way, why don't you link sfml-window? And the library order should actually be reversed.

[Anrock]

@Nexus, inside pretty long FindSFML.cmake and Terminus.ttf font, same as in my game, though you may try with any other font, i guess it doesn't matter anyway. Cmake module could be taken from repo as separate file.

I don't link window because error reproduces without it. (Should i link anyway?).
Linking order didn't change anything: cmake build still broken, manual still ok.
Anyway here is CMakeLists.txt

cmake_minimum_required(VERSION 2.8)

project(Test)

set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -g -O0 -std=c++11")
set (CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules" ${CMAKE_MODULE_PATH})

set (TEST_SOURCE test.cpp)

add_executable("Test" ${TEST_SOURCE})

find_package(SFML 2 REQUIRED window graphics system)
if(SFML_FOUND)
        include_directories(${SFML_INCLUDE_DIR})
endif()


target_link_libraries("Test" ${SFML_LIBRARIES})

file (COPY Terminus.ttf DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
 

And test.cpp:

#include <SFML/Graphics.hpp>

int main(int argc, char* argv[])
{
        sf::Font font;
        font.loadFromFile("Terminus.ttf");
        sf::Text text("OOPS", font, 14);
        return 0;
}
 

[Anrock]

Were you able to reproduce it?

[Nexus]

As mentioned before, you have to change the library order, so that dependent libraries are in front.

find_package(SFML 2 REQUIRED graphics window system)

It may work depending on the compiler, but at least earlier versions of g++ have a problem with it.

Have you found out what libraries are eventually linked? You can test with

message(${SFML_LIBRARIES})

Are those the same as you would link manually? What if you compile without -g -O0?

As Laurent mentioned, you should try to find out what's different in the CMake build from the manual build in order to find the problem.