Hi, recently my game begin segfaulting with this backtrace
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.
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, 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;
}
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.
@Nexus,
Reordering libs gives no effect.
SFML_LIBRARIES contain /usr/local/lib64/libsfml-graphics.so/usr/local/lib64/libsfml-window.so/usr/local/lib64/libsfml-system.so
Minimal example was compiling with -g and -O0 already.
Now things i did (note it's 4:49 am here, maybe i missed something):
1. I removed libsfml package in my package manager, deleted libsfml* in usr/local/lib64. Installed libsfml back in package manager. To get a fresh start, yeah.
2. Rerunned cmake and somehow it still find libsfml in /usr/local/lib64. Of course build failing as there is no such files. I've exported SFML_ROOT=/usr/lib64/ where .so really are. Cmake still finds libsfml in /usr/local/lib64.
3. Okay, i'll try other way. Commented out lines with find_package and related checks, replaced target_link_libraries with that:
target_link_libraries("Test" /usr/lib64/libsfml-graphics.so
/usr/lib64/libsfml-window.so /usr/lib64/libsfml-system.so)
to eliminate any FindSFML module influence.
With libs specified explicitly, font initialised fine.
I guess i had leftovers of libsfml 1.6 in /usr/local/lib64 and at the same time FindSFML wasn't checking /usr/lib sticking to /usr/local/lib instead and linking with libs of 1.6 version. Now leftovers gone and i'm sure libs installed are fine and not corrupted and code okay and cmake okay too. FindSFML is probably guilty of all that, what do you think?