SFML community forums
Help => Window => Topic started by: miki151 on April 12, 2016, 01:56:31 pm
-
A user is reporting that my game doesn't start, it just freezes without opening a window. I got a minidump file from him, the stacktrace is as follows:
sfml-system-2.dll!587d59c0() Unknown
sfml-system-2.dll!587d59cc() Unknown
sfml-system-2.dll!587d1096() Unknown
sfml-window-2.dll!0f099fd8() Unknown
sfml-window-2.dll!0f09311b() Unknown
sfml-window-2.dll!0f0950f4() Unknown
sfml-window-2.dll!0f09abce() Unknown
sfml-window-2.dll!0f095604() Unknown
sfml-window-2.dll!0f0949a8() Unknown
keeper.exe!Renderer::initialize() Line 268 C++
The last line is in my code, as follows (display is a RenderWindow).
display.create(sf::VideoMode::getDesktopMode(), "KeeperRL");
The method is called in an extra thread, while some stuff is done in the main thread first (RenderWindow constructor, Font::loadFromFile), could this cause any trouble?
EDIT: the problem persists even when the game is run in a single thread.
Is there any way to load the SFML symbols and see the whole stacktrace?
Note that this is a pretty uncommon bug, I couldn't reproduce it on many PCs, and the game has worked for lots of players for years. On that user's particular machine, we've tried a Visual Studio 14 build with the most recent SFML version, as well as a Mingw-w64 build with a slightly older verison of SFML.
The user's spec:
Windows 10
i7-4930K
GTX 970
-
What's his monitor resolution and what's the game's window resolution?
If the window resolution is larger than the screen resolution, then the window won't show. Not sure if that is really the problem here though.
If you want to load debug symbols, you need to rebuild SFML with that option.
-
The user that reported bug may have some issues with OpenGL drivers.
-
What's his monitor resolution and what's the game's window resolution?
I use sf::VideoMode::getDesktopMode(), so I suppose the window has the same resolution as the desktop?
If the window resolution is larger than the screen resolution, then the window won't show. Not sure if that is really the problem here though.
I know that on Windows the window is always slightly too big (it goes under task bar), maybe on Windows 10 it causes the call to hang. But I think that more users would report the problem if it was this trivial.
If you want to load debug symbols, you need to rebuild SFML with that option.
I sent him a debug build that loads the sfml-d dlls, will that get me a full stacktrace?
-
I sent him a debug build that loads the sfml-d dlls, will that get me a full stacktrace?
Depends if the debug symbols are actually included. If you use VS the symbols are not included in the DLL. You'd have to change the compiler flag in CMake to /Zi or use the latest git commit and enable the building of the PDB files which contain the debug symbols.
If you use MinGW the symbols should be included.
-
How do I add /Zi to the compiler command line via CMake?
Nevermind, I found the "Advanced" toggle in CMake-GUI. I noticed that /Zi is included by default in the debug build. Does that mean that the debug build in the binary release of SFML for Visual Studio is built with different flags than the default ones in the source code release?
-
I just checked again and we use already /Zi. To include the debug symbols you actually have to set /Z7.
Activate advanced options and replace the other /Zi flag in the CMAKE_CXX_FLAGS_DEBUG with /Z7.
-
Ok, thanks for the clarification. Is it ok to add /Z7 in release flags (CMAKE_CXX_FLAGS) or will that break something? I'd like to get proper stacktraces of SFML code in the production build of my game.
-
You can do that too, it could however have impact on performance in some way and will definitely make the library files (a bit) larger.
-
I added the /Z7 flag to release flags, but VS doesn't see the symbols for the dll file. Maybe I would have better luck with generating a pdb file along the dll? Is it easy to do that?
Binary was not built with debug information.
-
I added the /Z7 flag to release flags, but VS doesn't see the symbols for the dll file.
And you actually replaced the newly compiled SFML DLLs?
Maybe I would have better luck with generating a pdb file along the dll? Is it easy to do that?
If you use the master branch from GitHub, it's as easy as ticking a CMake option when building SFML.
-
And you actually replaced the newly compiled SFML DLLs?
Yeah, I double checked it. Maybe some other compiler flags need to be included to have the symbols in dlls?
If you use the master branch from GitHub, it's as easy as ticking a CMake option when building SFML.
Sounds nice. Is the master branch ok in terms of stability? I'd like to use this setup for production.
-
Yeah, I double checked it. Maybe some other compiler flags need to be included to have the symbols in dlls?
I wouldn't really know.
Sounds nice. Is the master branch ok in terms of stability? I'd like to use this setup for production.
In generally yes. As with any software, there could be bugs that were newly introduce but we don't yet know of.
-
I compiled SFML from master, I saw that the option to generate PDB was on by default, but I can't find the PDB files anywhere in the build directory...
-
They should be there, otherwise the recommended way to use CMake is to build the install target (while having set a writable directory for CMAKE_INSTALL_PREFIX).
-
Installed it, still no luck. Are the pdb files supposed to be generated for release build or perhaps only for debug?
-
For plain Release they won't be generated, you'll have to either use Debug or RelWithDebInfo.
-
That was the key problem :)