Just confirming everything now... The textures do disappear because of the drivers.
#0 64A3D420 ??() (C:\Windows\SysWOW64\nvoglv32.dll:??)
#1 6699772B sf::Texture::~Texture() () (C:\PROJEC~1\PROJEC~1\bin\Debug\sfml-graphics-2.dll:??)
#2 00BDCB78 ?? () (??:??)
#3 00000017 ?? () (??:??)
#4 ?? ?? () (??:??)
Points to the Nvidia OpenGL 32 library that was packed with this ever so buggy driver.
So yeah... Its busted...
On a side note... what scares me to think that this some how slipped WHQL inspection and became a "Stable" driver on the Nvidia web site and since its release they have done nothing to fix this ridiculous bug.
Just confirming everything now... The textures do disappear because of the drivers.
#0 64A3D420 ??() (C:\Windows\SysWOW64\nvoglv32.dll:??)
#1 6699772B sf::Texture::~Texture() () (C:\PROJEC~1\PROJEC~1\bin\Debug\sfml-graphics-2.dll:??)
#2 00BDCB78 ?? () (??:??)
#3 00000017 ?? () (??:??)
#4 ?? ?? () (??:??)
I have no clue how you come to this conclusion. The stack trace doesn't let you infer driver bugs.
Using std::map is not a problem per se -- you only have to be careful at the time of insertion, where a copy is performed. So that you don't let pointers refer to the local object which is inserted.
Other than that, we cannot say anything without code. The only way to find out whether drivers are the problem in your case is to come up with a complete and minimal example.