FreeGameDev

hiker {l Wrote}:Since it appears that you have this crash often, could you run stk in a debugger and provide a stack trace?

When reading this, I realized how common such a situation was for a project like STK. Plus, I think many users (well, players ) don't know how to compile STK in debug mode, run it into a debugger, what a stack trace is, etc.

For my own project, I recently created very simple code to get and print a nice stack trace when it crashes (in case I hadn't started it in the debugger).
I think such a feature could be useful for STK
So here is the "project":
http://dl.dropbox.com/u/20292682/backtrace.7z

It's really small (just a snippet actually), nothing fancy, it just works, but has only been tested on Linux (maybe works on MacOS X).
An equivalent code for Windows would use StackWalk64 I think.
I do plan on making a Windows version at some point.

You can compile the project just by typing "scons" (if you have SCons installed of course).
If you want to compile it by hand, add the "-g" and "-rdynamic" options.

Of course, the downside of systematically using -g and -rdynamic to produce STK's binaries is that they would be slightly bigger (symbols), but I don't think this would impact performance (please tell me if I am wrong).
The bright side is that anyone (well, for the moment anyone on a Unix-like system, which is really restrictive, I know ) would be able to give you a stack trace of any crash without the need of a debugger \o/ And a bug that is hardly reproducible would not be missed if the stack trace was logged into a file, instead of just printing it as is done in my example

That's just a snippet of code, and sadly it doesn't get the line numbers, the values of the variables, etc. We would need a real core dump for all that...(getting the line numbers would really be cool though).

This is in the public domain, feel free and welcome to modify it so that it suits your needs, if you are interested

I continued my investigation on this problem, and found this project: http://code.google.com/p/google-breakpad/

It's a real tool for core dumping, so yeah, it seems 1000x better than my poor snippet, it's cross-platform, etc etc
No idea how hard it is to integrate such a library, but I doubt it's hard to do...I'll have a closer look

This would be most interesting for Windows I think; on OSX there is the crash report dialog which includes a stack trace already. Maybe on linux this could be useful too, though maybe to a lesser extent.

Since Joerg is the Windows expert, I'll let him have a look

Really, you get the stack trace on OSX for free? That's really cool
And is it saved to some file? I mean, suppose a user experiments a crash, but doesn't manage to reproduce it, if it's not saved somewhere the information is definitely lost...

I totally agree that something like this is useful, and I already have started to look into this (on Windows there is a special API that apparently allows you to get this information). I am not sure, but shouldn't a linux executable always produce a stack trace anyway (if you run in a terminal window?)

Just having the symbols (and perhaps line numbers) should not affect the executable speed (if we ignore minor runtime variations since the memory layout can be different, which might impact cache performance, but I doubt that this is noticable).

Generally running in a debugger is better (esp. if the user has the session at hand and we meet on irc, since then we can look at some variable values), so some playtesters always run in gdb

It's just a matter of time and priorities Since we usually do get a stack trace, I never made this a high enough priority.

Cheers,
Joerg

hiker {l Wrote}:...some playtesters always run in gdb

Is there any other way?

Yup, from the quick look I had at the Windows way of doing it, it seems to be always based on DbgHelp.dll (StackWalk64 is part of it), and I think these links could be good starting points:
- http://www.gamedev.net/topic/457984-wal ... h-mingw32/
- http://stackoverflow.com/questions/3318 ... mingw-msys
- http://www.codeproject.com/KB/threads/StackWalker.aspx

Of course it doesn't replace a debugger but as I said in some cases one can't use a debugger or doesn't know what kind of animal a debugger is

I tried to compile one of these examples from my Linux box using MinGW and WINE, without much success

Funto {l Wrote}:Really, you get the stack trace on OSX for free? That's really cool
And is it saved to some file? I mean, suppose a user experiments a crash, but doesn't manage to reproduce it, if it's not saved somewhere the information is definitely lost...

yes, it's saved, though I have no idea for how long

Do you have to be using a debug build to get a useful stack trace?

LinuxUser {l Wrote}:Do you have to be using a debug build to get a useful stack trace?

Generally not, as long as there are some debug symbols in the binary

Auria {l Wrote}:

LinuxUser {l Wrote}:Do you have to be using a debug build to get a useful stack trace?

Generally not, as long as there are some debug symbols in the binary

So does the normal binary count?

I play on Windows, and have Visual Studio 2005, and I know how to attach the debugger to a process that has crashed, but what is it in there that is the stack trace? Call stack?

Yes, call stack is a synonym
As to whether the windows binary contains some debug symbols, I'll let Joerg answer as I don't know