Windows XP supported by SFML 2.4.2?

[CyanDog]

Hello, are the SFML devs still willing to look into XP specific bugs?

If yes, I believe I found a problem affecting Windows XP when SFML is linked statically. The resulting application¹ crashes before creating the window and the debugger breaks at:

src/SFML/System/Win32/MutexImpl.cpp:52

It seems that the EnterCriticalSection() function may be the problem.

This issue affects both Windows XP SP3 and Windows XP Mode, regardless of whether Visual Studio 2010 SP1 (v100) or Visual Studio 2017 (v141_xp) were used to build the application and SFML.

¹ resulting application = any SFML application, including any of its demos

[eXpl0it3r]

If I remember correctly we haven't officially done away with XP.

So what exactly is your setup?
You're running Windows XP with SP3 natively on some PC, correct?
Do you build on XP as well or on your non-XP machine.

Can you provide the complete call stack?

[CyanDog]

You're running Windows XP with SP3 natively on some PC, correct?
Do you build on XP as well or on your non-XP machine.

Yes, and yes. Building shared and static libraries without the SFML_USE_STATIC_STD_LIBS flag.

Note that if the .DLL's are used, everything runs fine. The crash only occurs for static linking of SFML2.

Can you provide the complete call stack?

Yes, let me know what exactly to copy-paste for you.

Code: [Select]

ntdll.dll!7c90100b()
  [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
> window-d.exe!sf::priv::MutexImpl::lock()  Line 52 + 0xc bytes C++


[eXpl0it3r]

The complete call stack from where the error origibates.

[CyanDog]

Code: [Select]

ntdll.dll!_RtlEnterCriticalSection@4()  + 0xb bytes
> window-d.exe!sf::priv::MutexImpl::lock()  Line 52 + 0xc bytes C++
  window-d.exe!sf::Mutex::lock()  Line 57 C++
  window-d.exe!sf::Lock::Lock(sf::Mutex & mutex)  Line 39 C++
  window-d.exe!sf::priv::ClockImpl::getCurrentTime()  Line 74 C++
  window-d.exe!sf::Clock::Clock()  Line 42 + 0x17 bytes C++
  window-d.exe!`anonymous namespace'::ConnectionCache::ConnectionCache()  Line 43 + 0x1f bytes C++
  window-d.exe!`vector constructor iterator'(void * __t, unsigned int __s, int __n, void * (void *)* __f)  + 0x17 bytes C++
  window-d.exe!`anonymous namespace'::`dynamic initializer for 'connectionCache''()  Line 49 + 0x16 bytes C++
  msvcr100d.dll!__initterm()  + 0x1c bytes
  window-d.exe!__tmainCRTStartup()  Line 473 + 0xf bytes C
  window-d.exe!mainCRTStartup()  Line 371 C
  kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes


[CyanDog]

Let me know (in this thread) when a bug-fix becomes available for testing, or if I need to provide more information. Thanks.

[eXpl0it3r]

Does the following short piece of code also crash?

#include <SFML/System.hpp>

namespace {
    sf::Mutex mutex;
}

int main() {
    sf::Lock lock(mutex);
}
 

[CyanDog]

Does the following short piece of code also crash?

No, it does not crash.

[eXpl0it3r]

After talking with binary1248 he seems to have found the culpit. It's not exactly a bug in SFML, but there's still a potential fix we can try.
As for your own code, it seems like you're using some static function call or similar (global variable) to store/construct an sf::Clock object. Since the sf::Clock object will get constructed in global scope, but since the mutex inside the sf::Clock is also in a global scope and because initialization order in a global scope is undefined, it just so happens that the sf::Clock gets initialized before the mutex gets initialized, causing a crash.
So you can fix this by not having an sf::Clock constructed in the global scope.

Additionally you could try and see if this change fixes the issue for you.
We'd actually be really glad if you could test this, since we rarely develop things on XP.

[CyanDog]

As for your own code, it seems like you're using some static function call or similar (global variable) to store/construct an sf::Clock object. Since the sf::Clock object will get constructed in global scope, but since the mutex inside the sf::Clock is also in a global scope and because initialization order in a global scope is undefined, it just so happens that the sf::Clock gets initialized before the mutex gets initialized, causing a crash.
So you can fix this by not having an sf::Clock constructed in the global scope.

Note that this bug affected the unmodified SFML demos as well, not just my test projects. That said, well done finding the location of the bug. This is the first time I see the "static initialization order fiasco" in a real project.

Additionally you could try and see if this change fixes the issue for you.
We'd actually be really glad if you could test this, since we rarely develop things on XP.

Confirming that the above patch fixes the problem on¹:

• Windows XP SP3, Visual Studio 2010 SP1
• Windows XP Mode (Windows 7 SP1), Visual Studio 2010 SP1
• Windows XP Mode (Windows 7 SP1), Visual Studio 2017
• Windows XP SP3, Visual Studio 2017

¹ I will edit this post to include test results for Windows XP Mode and VS2017.

Also, I too am glad that you didn't drop support for Windows XP yet, and hoping that you won't do soon. I consider the 32-bit world to be a sweet spot that shouldn't be thrown in the trash yet.