Don’t know if anyone else has encountered this, but the game doesn’t seem to play nice with MSI Afterburner. Opening MSI Afterburner when the game is already open crashes the game. Opening the game when MSI Afterburner is already open… sometimes crashes the game, I think? Other times the on-screen framerate display just doesn’t work.
Not sure where to even begin with this but thought I would bring it up anyway. I have this error log from the user:
Thank you kindly, I will send it over to them to see.
I’m not generating debug symbols, but happy to do so in the future. A quick search to explain what they are leaves me a little but not much wiser. Should I always be generating debug symbols? Is there a cost?
Debug symbols are necessary to make non-vanilla crash logs useful to see what is going wrong. They do not have a real cost to generate, for release builds like you are doing with a live audience they are very important to generate and store.
If the engine crashes the debug symbols are used to turn a meaningless callstack of memory addresses into a list of names of the functions that were called when the crash occurred. This greatly helps when debugging. On some platforms the debug symbols are included inside the engine binary and on some platforms it is a separate file. On platforms where the symbols are included in the engine binary it obviously increases the size.
In release builds we strip the debug symbols from the engine, but we provide them as a separate file, which later can be used to symbolicate a crash, ie turn the memory addresses into function names.
For vanilla builds, ie builds without native extensions, we provide the debug symbols as downloadable files on our download server (d.defold.com). Files such as dmengine.js.symbols and dmengine_release.dSYM.zip are examples of such files.
For builds which include native extensions the debug symbols for the vanilla engine will not work. When you bundle your application you have an option in the Editor to “Generate debug symbols” and from bob.jar there is --with-symbols. The debug symbols will be downloaded together with your application bundle. You should make a habit of always generating debug symbols and storing these per released version of your game.
That callstack looks weird to be honest. There’s no reason memset should call UnhandledExceptionFilter and then end up in OpenAL (alcCreateContext).
But as the others mentioned, what we’d like to see is the unstripped executable and also the _crash file from the user (although most of that data is in the post you have there)
Creating a build with debug symbols creates another file called “dmengine.pdb”. Do I include that file in the build I push to Steam, or take it out? Just want to make sure either way.
Will this mean a new type of error log is created (_crash)? If so, where can I tell the user to search for it? If not, is there something additional I need to put in my code first? My game currently has a user set toggle option to use either Err for local error files or defold-googleanalytics to upload exceptions automatically.
No need to upload it to Steam. Keep it around and make sure you know which Steam release the .pdb file belongs to!
This is always created when a crash happens. It contains the call stack. The callstack+dmengine.pdb allows us to get a better understanding of what’s going on.
Good to know! Do I need to set it one aside for each OS I build to, or are they all the same if the only difference is the target OS?
Yes, I think so. The info I posted at the beginning of the thread was from an Err-generated log. For GA I also believe it’s captured, like this example (not as pretty):
Also, on windows, the crash extension generates a _crash.dmp, which is even more useful to us, since that (and the exe plus pdb) allows us to debug the crash much more easily.
I’ve restructured the Debugging manuals a bit and included some of the information from the thread. There is now a new Debugging section in the menu on the left and a bunch of pages:
From the key you provided, I tried running both Fairy Solitaire and the remastered version.
Starting the game first, then starting MSI Afterburner, and vice versa.
For both versions.
They seemed to work fine.
The original version froze with a black screen the first time, but the next couple of times it worked.
No crashes.
I asked for clarification and the answer is that FSR never had any issues. The black screen in the original happened only once, and the user was unable to reproduce it.
