- 3D Stuff (9)
- BumpTop (5)
- C/C++ (16)
- Open Source (6)
- Radiant (8)
- Seneca (4)
- Stuff (11)
- Uncategorized (14)
- win32 (11)
- November 10, 2008: Radiant Update
- October 28, 2008: Primary Export: Pain
- September 7, 2008: Results
- September 5, 2008: Multicore Processing And Game Engines
- July 31, 2008: Work++; // Again!
- June 8, 2008: Patterns And Such.
- June 4, 2008: Work++;
- May 20, 2008: SIMD And Randomness
- April 30, 2008: Coder Burn-Out
- March 26, 2008: Some GameDev Math Resources.
Exception Reported!
The last few weeks or so were ridiculously busy at work. The BumpTop internal alpha release is nearly completed and we will be shipping it out to a select few so that they can test it. I am really excited to put the 10,000+ lines of code that I have added to the project to the test in the real world. All of it has been a challenge thus far and as a consequence, it probably contains numerous bugs that I alone was not able to find. So, before the alpha is being shipped out, I am adding a neat snippet of code that allows me to do a stack trace on the executable. This snippet of code dumps the call stack and current variables to a file and then emails it to me for debugging purposes. Unfortunately for all the people that shun the Microsoft C++ Compiler, this is only available using it because the compiler itself exports a debugging database, which the crash can use to identify symbols (variables, line numbers, function names, etc). There might be other compilers out there that export symbols or failmaps, but since this is all new to me, I have only tried it using Visual Studio.
So, on to the code. Now before you scroll down and click the link, let me explain how this code works. Firstly, it uses Structured Exception Handling (SEH), which is much like C++ exception handling but its proprietary to Microsoft. The difference is that SEH does not call the destructor on local objects when the exception is caught, while regular C++ exception handling does. Secondly, the syntax for this type of exception handling is rather different because it uses the proprietary __try and __except keywords to catch the exception. The __except keyword can call a specific type of function that is referred to as a “Filter” by MSDN. This filter is where all your stack tracing and memory dumping can happen. Within this filter, I access a library by the name of DBGHLP.DLL. It contains a function that will dump the contents of a call stack into a file. This dump can be opened by Visual Studio and run much like a regular program. At that point, the contents of the crash can be seen and easily debugged by the programmer. But enough chit-chat, here is the Code.
Also, since the BumpTop alpha is going out internally the public alpha will be available very soon (within a week or two). If anyone is interested in helping with beta testing, please send me an email to mark(NO_SPAM)@bumptop.com. Please remove the (NO_SPAM) string in the email address.