sf::Text destruction causes segfault

[JAKUBW]

Hey everyone, I have got a question. Why does this code cause segfault?

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

int main()
{
        {
                std::cout << 1 << std::endl;
                sf::Text text;
                std::cout << 2 << std::endl;
                text.setString("Hello world");
                std::cout << 3 << std::endl;
        }
        std::cout << 4 << std::endl;
}
 

After successfully compilation (and run) with this command:

g++-7 -std=c++17 -c main.cpp&&g++-7 main.o -o sfml-app -lsfml-graphics -lsfml-window -lsfml-system&&./sfml-app
It prints me:

1
2
3
Naruszenie ochrony pamięci

Naruszenie ochrony pamięci is Segmentation fault in polish

I use Linux Mint 64bit

[eXpl0it3r]

Use a debugger and check the callstack.

Since you use a very recent compiler, did you also build SFML with the same compiler?

[aggsol]

Funny, I have a similar problem with sf::VertexArray. I am investigating it with valgrind, it is something the its destructor. I use g++ 4.8.5 and SFML 2.4.2. I'll keep you posted...

[JAKUBW]

No, I didn't build SFML with the same compiler. I have just typed this:

sudo apt-get install libsfml-dev

And then

g++-7 -std=c++17 -c main.cpp&&g++-7 main.o -o sfml-app -lsfml-graphics -lsfml-window -lsfml-system&&./sfml-app

Like it is in the tutorial https://www.sfml-dev.org/tutorials/2.4/start-linux.php

[aggsol]

I think my pre build SFML is not working with the compilers I use. With SFML 2.3.2 and g++ 5.4.1 on another machine problem is still the same. gdb  points to the destructor.

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x7fff00000006) at malloc.c:2951
2951   malloc.c: No such file or directory.
(gdb) bt
#0  __GI___libc_free (mem=0x7fff00000006) at malloc.c:2951
#1  0x0000000000486b20 in __gnu_cxx::new_allocator<sf::Vertex>::deallocate (this=0x7fffffffdea8,
    __p=0x7fff00000006) at /usr/include/c++/5/ext/new_allocator.h:110
#2  0x0000000000486aee in std::allocator_traits<std::allocator<sf::Vertex> >::deallocate (__a=...,
    __p=0x7fff00000006, __n=14757388222308182547) at /usr/include/c++/5/bits/alloc_traits.h:517
#3  0x0000000000486a8e in std::__cxx1998::_Vector_base<sf::Vertex, std::allocator<sf::Vertex> >::_M_deallocate (this=0x7fffffffdea8, __p=0x7fff00000006, __n=14757388222308182547)
    at /usr/include/c++/5/bits/stl_vector.h:178
#4  0x00000000004869f8 in std::__cxx1998::_Vector_base<sf::Vertex, std::allocator<sf::Vertex> >::~_Vector_base (this=0x7fffffffdea8, __in_chrg=<optimized out>)
    at /usr/include/c++/5/bits/stl_vector.h:160
#5  0x0000000000486987 in std::__cxx1998::vector<sf::Vertex, std::allocator<sf::Vertex> >::~vector
    (this=0x7fffffffdea8, __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_vector.h:425
#6  0x00000000004868ba in std::__debug::vector<sf::Vertex, std::allocator<sf::Vertex> >::~vector (
    this=0x7fffffffde90, __in_chrg=<optimized out>) at /usr/include/c++/5/debug/vector:208
#7  0x00000000004868f2 in sf::VertexArray::~VertexArray (this=0x7fffffffde88,
    __in_chrg=<optimized out>) at /usr/include/SFML/Graphics/VertexArray.hpp:45

I will refrain from using VertexArray anyway and will build SFML myself.

[eXpl0it3r]

Since you manually specify g++-7 you're using a newer compiler version. ABI can break between major version compiler updates, as such you can't expect SFML built with GCC 5 or similar to just work with GCC 7.