James Wynn

Debugging an application after its been released can be a total pain.  So, over time I've collected some software and techniques for making it a bit easier on myself and my team.  We ship our product with a modified version of  Hans Dietrich's XCrashReport to provide logs, system information, and minidumps when our application inevitably crashes. If you're not already using something similar I would highly recommend checking it out.

This utility sends us lots of crash dump files and until now we've always had to dig back through our archives to find the corresponding symbols and source code. But today I decided to rid us of the headache and set up a Symbol Server that could automatically determine our version and load it into Visual Studio 2008. The documentation can be a bit lacking at times, so I will try to illuminate the path that I took.

Step 1:
Download Debugging Tools for Windows. This provides you with symstore.exe which will be important for creating the symbol store.

Step 1.5:
Add the Debugging Tools directory to your path, so we have access to symstore.exe.

Step 2:
Create a folder on your build server and share it such that you have something like \\BuildServer\Symbols available to your workstation.

Step 3:
For each build, execute a command like

symstore.exe add /r /p /f U:\Project\Bin\*.* /s \\BuildServer\Symbols /t "My Project" /v "Build 42"

Where U:\Project\Bin is the directory with your .pdb files, \\BuildServer\Symbols is obviously the symbols directory, "My Project" is the name of the project, and "Build 42" is the description of the version.

Step 4:
Open Visual Studio 2008,  go to Tools->Options->Debugging->Symbols. Set your cache directory to something like C:\SymbolCache, then add the location of the new symbol store: \\BuildServer\Symbols.

Step 4.5:
At this point, it would be advisable to add the Microsoft Symbol Store to the locations list too: http://msdl.microsoft.com/download/symbols.

This should facilitate debugging crash dumps without tracking down the symbols. Also, check out the Source Server which will access your VCS system to pull out the correct source code files for you automatically too.

I finally got around to doing a little more work on FileWatcher and decided it needed an official home.  Then comes the compoundingly obvious problem of giving a product such a generic title.  Sure FileWatcher fits the purpose, but there are about 1.5 billion other projects/products with the same title.  So the new title is SimpleFileWatcher, and with that comes two new features for users of SimpleFileWatcher.  SFW is now under the MIT License, so no worries about using the code in commercial products.  And secondly, it is hosted on Google Code.

SimpleFileWatcher

And the new release:

SimpleFileWatcher v.2009.05.14

Lua is a fantastically lightweight and super fast scripting language that is the current defacto standard in-game language. Use in many many games, including the infamous World of Warcraft. We used it in my last project with great success as well, but we were never quite satisfied with the level of integration.  And this really stems from the main detractor of Lua. There is no fantastic binding system for gluing it to C++. There are many out there to be sure, but most fall short. The most popular seem to be toLua++ and LuaBind.

toLua++ was the route we decided to go with our last system, but this had caveats.  The system required us to maintain extra "doctored" copies of our headers that could be used for generating the binding code.  This duplicated data caused headaches more than once.  That aside, there were problems with memory bloat, and memory leaks. From what I understand, these issues are known and have yet to be delt with.

LuaBind is probably the most used (rivaled only by toLua++) binding system right now.  It has a few glaring issues of its own though.  Most notably is its heavy use of the boost library.  Boost is a fantastic set of facilities, but it is just too bloated for a project not already reliant on it. This requirement caused builds to take significantly longer due to its heavy use of meta-template programming (something boost users are apparently comfortable with.)  LuaBind also makes my Lua IDE, Decoda, practically unusably sluggish. I'm not sure what is affecting it, but I assume it has something to do with the inflated symbol files it has to parse.

A few runners up that I'm currently considering now are LuaBridge and SLB (Simple Lua Binder). Both of these libraries are essentially building a LuaBind clone without the boost dependency. LuaBridge hasn't been updated in over 18 months, and is as well as dead, so the plan of action would be to pick up where the original author left off.  While the author of SLB hasn't posted any updates in months, he has been committing code regularly to the googlecode repository. Right now I'm hoping SLB pans out, but we will see.

Anyone else have a good recommendation?

Now not only does FileWatcher support Win32 and Linux, but it supports OSX/BSD/anything else using kqueue. This should cover 90% of the cases where this functionality is needed and I'm planning on a fallback mode that will just use directory scans and file timestamps to determine changes.

Get the new version here:
FileWatcher 2009.03.04