I''m kind of a n00b with exception handling, and I was wondering how you get call-stack information - like in Unreal when it crashed they dumped the call-stack. How they do?

So there''s no automated way to do this? You need to catch/rethrow in everywhere you want call-stack information?

Under Win32, you can use the DBGHELP functions to walk the stack (ie. build a stack backtrace like in the debugger). If you have symbol files with your executable (even just the public symbols), you can use those to resolve function names, etc on the stack (and sometimes provide parameter info too).

If you have used windbg (from the Windows DDK/SDK), then you''re probably already familiar with this (the ''kb'' command in windbg generates the back trace).


-Brannon

I''ve used wind bag from time to time, but am not familar with every thing it can do.

Cool thanks Brannon, I''ll read up on using sysmbol files and minidumps - it should be possible to pin-point the line of your source a crash occured at and do a call-stack trace to show the execution in a release build using the symbol file generated by the compiler...

Check out the MSDN "Under the Hood" articles from April and May of 1997 - the April article shows how to catch unhandled exceptions and walk the stack backwards from there - the May article shows how to use the ImageHelp.dll to correlate the stackwalk info with the debug info. Because Imagehlp.dll has been superceded by dbghelp.dll - you''ll have to put a little work into using the tricks from the second article.

‘But truth's a menace, science a public danger.’ Brave New World, Aldous Huxley

I basically agree with Kylotan, that I think they use macros to do it. However, you don''t need to use exception handling for it to work.

You could create Singleton a StackHistory class that is basically a LIFO container to keep track of stack information. Then create a StackEntry class that takes a string (the class/function) as it''s constructor parameter. This class will automatcially communicate with StackHistory to push this new entry in the constructor, and pop this entry in the destructor.

Since the destructor gets called automatically when the function exits then you only need one macro at the start of the function, and no ending macros, which would be a pain since many functions have multiple exit points.

Although you don''t need a macro, it''s very useful here because it allows you to automatically record the file/line number with the class/function name, as well as allowing you to turn off the stack tracing by redefining the macro.

BTW, this stack tracing approach also makes it very easy to add code that times each function, thus giving you your own profiler.

The reason I like this approach so much better than DBGHELP is because it''s platform independant, which is very important to me.


- Houdini

I have this funny feeling in my gut that tells me MiniDumpCallStack is approx. 10000000000000000000000000000000% faster than the daisy-chained exception/linked-list methods
Still, I wonder how they did it with Unreal ''cause the dialog box that pops up shows the whole decorated call-stack right in front of you.

The Dump method has the _added_ advantage that it requires the symbol file - this way clients can have automated error reporting, but they don''t have the symbols there to hack it (like they would with the ensueing string table the other methods would create). Also it could show the user what it''s sending, and it''ll look like a core-dump, like random crap to the untrained eye. But you have a nice little program that reads the dump and your symbol file and out pops:

printf("The buggy pos whacked the meat on line %l in file %s.  Last editted by %s on %s.", iLine, szFile, szWhoDoneIt, szWhen); 

And the rest of the call-stack ensues...