Static vector and static array of sf::Texture, segfault

[miso2271]

Hello, i have a problem with static member sf::Texture arrays, could you please tell me what i did wrong?

Compiler: Visual C++ 2019 v142
SFML libraries compiled by me with the same compiler.

Code at the bottom.

When i try to create a static member array or a static member vector of sf::Texture and try to resize it or set its size on declaration, i get a segfault (seen below in call stack, very short). This does NOT happen when the array/vector is not a static member variable, it works fine, nor does it happen with other SFML classes, only sf::Texture. Vector::resize constructs new objects of sf::Texture with default constructor and an array does the same thing, that is create an empty texture object, so i can't think of a reason for this. This didn't happen at all when i used the Mingw version with GCC compiler.

I am doing this in order to load textures for each different game entity so that they are loaded only once in the respective class.

I should also mention that Release version works without any issues, the textures load and the game runs, only Debug version segfaults.
I am using static linked SFML, they are linked in this order: graphics, window, system. Their dependencies are linked in a random order before them. This shouldn't be wrong as there are no linker errors.



This does not work in Debug, segfault but works in Release.

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

using namespace std;
class Container {
        static sf::Texture textures[6];
};
sf::Texture Container::textures[6];
int main() {
        return 0;
}
//////////////////////////////////////////////////////////////

Call Stack

        ntdll.dll!77d46015()    Unknown
        ntdll.dll![Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]       Unknown
>       Test.exe!sf::priv::MutexImpl::lock() Line 52    C++
        Test.exe!sf::Mutex::lock() Line 57      C++
        Test.exe!sf::Lock::Lock(sf::Mutex & mutex) Line 39      C++
        Test.exe!sf::priv::GlContext::initResource() Line 245   C++
        Test.exe!sf::GlResource::GlResource() Line 38   C++
        Test.exe!sf::Texture::Texture() Line 73 C++
        [External Code]
        Test.exe!`dynamic initializer for 'Container::textures''() Line 11      C++
        [External Code]

/////////////////////////////////////
But this does!

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

using namespace std;
class Container {
        static sf::RectangleShape rectangles[6];
};
sf::RectangleShape Container::rectangles[6];
int main() {
       
        return 0;
}
 

[eXpl0it3r]

You can't initialize SFML resources are global scope, which static initialization is, because the initialization and deallocation order of global objects is undefined and SFML itself does make use of globals to provide an unified API.

[miso2271]

You can't initialize SFML resources are global scope, which static initialization is, because the initialization and deallocation order of global objects is undefined and SFML itself does make use of globals to provide an unified API.

Really? It works perfectly when sfml is linked dynamically. Guess i'll have to learn a better method of storing textures if i want static linking. Thanks!

[Laurent]

Really? It works perfectly when sfml is linked dynamically

Global objects that live inside dynamically loaded libraries may be initialized before global objects that live in your code. When you link statically, everything is initialized in the same binary (your executable) and then the order is undefined (which means that sometimes, it may work as well, and sometimes not).

Guess i'll have to learn a better method of storing textures

Definitely. Global variables (whether free or static inside a class) are usually not a good design. They should always be owned by some object, that controls their lifetime in a determinist way.