Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Shannon Barber

Call Stack information and exceptions

This topic is 6002 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
(edit: ignore what was here previously: it made no sense cos I misread something).

I think they use macros at the start and end of each function: the first macro basically starts a try block, and the last macro is a catch block that outputs the function name before rethrowing the exception. Or something like that.

Edited by - Kylotan on January 12, 2002 3:45:36 PM

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!