Crash w/ VC++ 2010, SFML static libs and static sf::Texture?

[iwn]

Good day,

Take the following program:

Code: [Select]


#include <SFML/Graphics.hpp>

sf::Texture texture;

int main() {
  return 0;
}


When compiled with MinGW g++ against SFML DLLs, it runs successfully.

When compiled with MinGW g++ against SFML static libs, it runs successfully.

When compiled with VC++ 2010 against SFML DLLs, it runs successfully.

When compiled with VC++ 2010 against SFML static libs, it crashes with the call stack:

Code: [Select]


  ntdll.dll!77aa22c2()
  [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
> testimage.exe!sf::priv::MutexImpl::Lock()  Line 52 + 0xc bytes C++
  testimage.exe!sf::Mutex::Lock()  Line 62 C++
  testimage.exe!sf::Lock::Lock(sf::Mutex & mutex)  Line 39 C++
  testimage.exe!sf::GlResource::GlResource()  Line 52 + 0xd bytes C++
  testimage.exe!sf::Texture::Texture()  Line 48 + 0x16 bytes C++
  testimage.exe!`dynamic initializer for 'texture''()  Line 3 + 0x28 bytes C++
  msvcr100d.dll!_initterm(void (void)* * pfbegin, void (void)* * pfend)  Line 873 C
  testimage.exe!__tmainCRTStartup()  Line 473 + 0xf bytes C
  testimage.exe!mainCRTStartup()  Line 371 C
  kernel32.dll!7530339a()
  ntdll.dll!77ab9ed2()
  ntdll.dll!77ab9ea5()


Could anyone more experienced than I please explain why this happens in the one instance and not the others?

[Laurent]

When you say "SFML static libs", is it just BUILD_SHARED_LIBS which is disabled, or did you also enable STATIC_STD_LIBS?

But anyway, avoid globals, especially SFML resources that use OpenGL and require an OpenGL context, they will always cause problems.

[iwn]

When you say "SFML static libs", is it just BUILD_SHARED_LIBS which is disabled, or did you also enable STATIC_STD_LIBS?

Just BUILD_SHARED_LIBS. STATIC_STD_LIBS is FALSE in all of my tests.

But anyway, avoid globals, especially SFML resources that use OpenGL and require an OpenGL context, they will always cause problems.

I had one instance where I was using a Texture as a static class member, and that led me to the aforementioned behavior when compiling with Visual C++. I then realized that it probably wasn't a very good idea in the first place, but I was still curious as to why it was happening.

I suspect it is related to something like the "static initialization order fiasco" described in the C++ FAQ Lite:

  http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14

Figured I'd ask just in case anyone knew more specifically how things could have gone awry.

Thanks for your response.

[Laurent]

I suspect it is related to something like the "static initialization order fiasco"

It is. Since SFML uses globals, no one can ensure that they will be initialized before your own globals (when you link SFML statically).

[Atomical]

Hello, are you by any chance using the Intel HD graphics driver?