Monday, June 18, 2012

The Power of Source Control

As well as helping to protect your work, source control can be a great debugging aid.

I'm debugging a crash with a recently released map.  Stepping through in the debugger I can see enough to tell me that it's most likely a garbled network message during the client signon sequence.  Great!  They're almost impossible to debug normally.

So, currently I'm on revision 424 of the code.  Jump back to revision 380, run it - no crash.  Try 400, run it, no crash.  420 - crash.

OK, so the code change that causes it happened somewhere between 400 and 420, let's try 410.  Yup, crashes.  And so to 405.

Eventually, by this process, I'm going to find the last revision where it didn't crash.  Then I can check out the code for that revision and the one after (where it did), diff them, bring on the changes between them one at a time, and identify the exact source of the crash.

Is that awesome or what?

6 comments:

mhquake said...

...and the cause was triggered by setting syncbase for static entities. Obviously something else in the group animation code I need to look closer at.

Anonymous said...

git/svn/hg bisect is helpful in this scenario.

Ron Jones said...

I tend to be stupid about source control. I use it, but don't commit frequently enough, and sometimes (occasionally) commit un-compilable or otherwise untested and broken code. It's a powerful tool when utilized the right way, but regrettably my brain hasn't gotten a handle on the 'right way' yet :)

Anonymous said...

I'm not a programmer, but watching Ryan Gordon's Flourish2012 talk he talked a while about new developments in debugging that are supposed to make your life easier -- he talks about Google Breakpad, Valgrind, GDB7 reverse debugging, Clang and also about version control with Mercurial and GIT.

http://youtu.be/r3wDnOAjrtk
(the debugging part starts at around 36 min)

mhquake said...

...and it turned out to be setting ent->syncbase based on the value of ent->model->synctype in CL_ParseStatic, but without checking if ent->model was NULL first.

Causing a stray jump to a random part of code, where it looked as though it was a network message.

mhquake said...

It's definitely a powerful concept. I don't think a tool to automate the binary search is of much utility to me as I generally commit in chunks 2 or 3 times per day. A single line of code could be the source of the bug (or having some code outside a condition instead of inside it, as in this case) so it seems to me that unless you've got something that auto-commits every single change you're going to need to search manually. Which is no big deal anyway.