Hi Laurent,
Using SFML2's Texture class we have discovered the following issues:
First, and least: copying an uninitialised Texture causes an error message to be printed. This could be avoided by changing Texture's copy constructor to
{
if (copy.myTexture)
LoadFromImage(copy.CopyToImage());
}
Second, when a Texture is destroyed it may use the static Mutex declared in Window/Win32/WglContext.cpp, on line 314. If a static Texture (such as, in our case, an entry in a static/singleton Texture repository class) is destroyed after that Mutex has been destructed, it will cause an access violation. Since it is basically impossible to control the order of destruction for static objects, a destructor should not access any static members, directly or indirectly. We are not familiar enough with SFML's inner structure to feel comfortable suggesting a solution to this problem.
The third issue is not related to Textures, as far as we're aware. We've encountered an access violation in System/Win32/ThreadLocalImpl.cpp, on line 52. The member myIndex had a value characteristic of freed heap memory (0xFEEEFEEE), suggesting that the ThreadLocalImpl object had been destructed. Unfortunately the call stack did not give any useful context in this case, but since it occurred after issue two, above, it is likely a similar problem.
