Messages

1

Graphics / Re: Global Texture Causing Segfault [SOLVED]

« on: March 12, 2016, 02:14:27 am »

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

2

Graphics / Re: Global Texture Causing Segfault

« on: March 12, 2016, 12:39:16 am »

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

3

Graphics / Global Texture Causing Segfault [SOLVED]

« on: March 11, 2016, 10:00:37 pm »

// 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?