[Solved] Read Access Violation: "mutex" in GlContext.cpp

[Qu32n]

Hello! 

I'm using SFML 2.5.1 for Visual C++ 15 (2017) - 32-bit

This bug only seems to happen in the following situations:
1) You're using STATIC linking
2) You declare an extern object that inherits from sf::GlContext

This is the code needed to reproduce the bug:

// Header.hpp
#pragma once
#include <SFML/Graphics.hpp>

// Exception in GlContext.cpp
// Line 245: pointer variable "(anonymous namespace)::mutex::m_mutexImpl" was NULL
extern sf::Texture UIButtonTexture;
 

// Header.cpp
#include "Header.h"
// Variable is never used.
sf::Texture UIButtonTexture;
 

As far as I know, sf::Mutex::Mutex() is never called in the program heap for some reason, therefor making Mutex::m_mutexImpl == nullptr.

This ultimately causes a read access violation in Mutex::lock()

// SFML/System/Mutex.cpp
void Mutex::lock()
{
    // Read violation; m_mutexImpl is nullptr
    // Note that it WILL call lock() but will fail when it tries to access
    // it's members because the 'this' pointer is nullptr.
    m_mutexImpl->lock();
}
 

I tried making my extern variable a pointer, but it resulted in the same error.

I'm not sure why sf::Mutex `anonymous-namespace'::mutex's constructor is never called.
But alas, I'm reporting this bug in the hopes that someone will figure out what went wrong! 

Cheers!

[eXpl0it3r]

You're declaring and initializing a texture in global scope. The initialization order of global objects is undefined.

Simply put, you can't initialize SFML resources in global scope.

[Qu32n]

The initialization order of global objects is undefined.

Ah, that makes a lot of sense

Thanks for the help! Sorry for the dumb question