std::exit()

[thePyro_13]

Currently sfml will cause a crash(MSVC2022) if std::exit is called after using any of the SFML Graphics objects.

In the debugger the crash appears in GLContext.cpp:752 when calling the elements in contextDestroyCallbacks.
This is because std::exit will skip destruction of stack objects, but will still call static global objects destructors.
I think this is during the destructor of the global shared context.

This might be fixed by sticking the static global objects into a static global struct together, so that the callback list won't be destroyed before the shared context. SFML could also register a function to clear the shared context before the static objects are destroyed using std::atexit.

I've moved to using std::quick_exit, but I think it would be worth it to get std::exit working with SFML.

[eXpl0it3r]

It can also be prevented by doing a clean exit instead of calling std::exit, which is considered bad practice anyways. You can't control all the globals of all the libraries in the world, so it's better to rely on cleanly returning from the main function.

I don't think it's possible to utilize a static global struct that bundles the global initialization, because we have cross-dependencies. Some parts are in sfml-window and some in sfml-graphics. Additionally, I'm not even sure if the destruction order of a global static struct is guaranteed.

[thePyro_13]

The only crash I experienced was due to a dependency between sharedContext and contextDestroyCallbacks.

Since both are static they are only accessed from within GLContext.cpp the issue can be resolved by putting those two into a static struct and manually destructing the sharedContext first:

static struct SharedContextStruct {
            ~SharedContextStruct() noexcept
            {
                sharedContext.reset();
            }

            std::unique_ptr<ContextType> sharedContext;
            ContextDestroyCallbacks contextDestroyCallbacks;
        } sharedContextData;

This doesn't change any of the other interactions with these objects, except to add the member access, but will ensure that sharedContext is always destroyed before contextDestroyCallbacks.

EDIT: There shouldn't be any risk of accessing already destroyed objects through this, since those objects destructors should have removed them from the calback list.