Global Texture Causing Segfault [SOLVED]

[BourgondAries]

// test.cpp
#include <SFML/Graphics.hpp>
sf::Texture _;
int main() {}
 

Built using the static libraries from SFML version 2.3.2, using the make:

g++ -g -DSFML_STATIC test.cpp -L . -l sfml-graphics-s-d -l sfml-window-s-d -l sfml-system-s-d -lSDL -lfreetype -lGL -lGLEW -lxcb -lX11 -lXrandr -lX11-xcb -lpthread -ljpeg -lGLU -lsndfile -lm -lopenal -lxcb-randr -ludev -lxcb-image -lpthread -I ../SFML-2.3.2/include/
 

SFML works correctly with local textures and windows, only when declaring a texture globally, a segfault will appear:

(gdb) r
Starting program: /home/kefin/stuf/docs/MLB-FiM/ok
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x7ffff6098e80 <initial>)
    at ../nptl/pthread_mutex_lock.c:66
66      ../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0  __GI___pthread_mutex_lock (mutex=0x7ffff6098e80 <initial>)
    at ../nptl/pthread_mutex_lock.c:66
#1  0x00000000004468b2 in sf::priv::MutexImpl::lock (this=0x0)
    at /home/kefin/stuf/docs/SFML-2.3.2/src/SFML/System/Unix/MutexImpl.cpp:57
#2  0x0000000000441353 in sf::Mutex::lock (
    this=0x65f960 <_ZN12_GLOBAL__N_15mutexE>)
    at /home/kefin/stuf/docs/SFML-2.3.2/src/SFML/System/Mutex.cpp:56
#3  0x0000000000441290 in sf::Lock::Lock (this=0x7fffffffde30, mutex=...)
    at /home/kefin/stuf/docs/SFML-2.3.2/src/SFML/System/Lock.cpp:38
#4  0x0000000000428fd0 in sf::GlResource::GlResource (this=0x65f0a0 <_>)
    at /home/kefin/stuf/docs/SFML-2.3.2/src/SFML/Window/GlResource.cpp:49
#5  0x00000000004069e9 in sf::Texture::Texture (this=0x65f0a0 <_>)
    at /home/kefin/stuf/docs/SFML-2.3.2/src/SFML/Graphics/Texture.cpp:82
#6  0x00000000004068ef in __static_initialization_and_destruction_0 (
    __initialize_p=1, __priority=65535) at test.cpp:2
#7  0x0000000000406918 in _GLOBAL__sub_I__ () at test.cpp:3
#8  0x0000000000446a4d in __libc_csu_init ()
#9  0x00007ffff5cfae55 in __libc_start_main (main=0x4068bd <main()>, argc=1,
    argv=0x7fffffffdfd8, init=0x446a00 <__libc_csu_init>, 3
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfc8)
    at libc-start.c:246
#10 0x00000000004067f9 in _start ()
 

So why does this happen?

[eXpl0it3r]

This happens because SFML uses globals internally as well which then leads to issues.

Moral of the story, don't use global SFML resources, actually don't use globals at all. There are nearly always better designs!

[BourgondAries]

This must be new then, because I'm trying to recompile a program from 2012, which is rather unfortunate.

[eXpl0it3r]

Using global SFML resources has always been discouraged. With older implementations you might simply been lucky and didn't run into issues.

[BourgondAries]

Hehe, naive young coder-me made such terrible mistakes as global variables. SOLUTION: I'll just port the program manually. Marked as solved.