Advanced Topic 1 of 5: Debugging

[Baker]

[mh]

I always use the debug build and always run in the debugger during development. Quite religiously.

There's no real hard and fast science to it, just a lot of setting breakpoints, inspecting values of variables, selectively commenting out sections of code to try to isolate problems, and a hell of a lot of experience built up over the years so that I sometimes intuitively "know" where a bug is.

Debugging isn't just about crashes; it's also about correct behaviour. It's possible to have a program that doesn't crash but still behaves incorrectly.

Catching potential bugs before they happen is important. I like to build up new code incrementally in layers and test at each layer. Make sure that part of it is working right before moving on to the next. For the same reason I hate just copy/pasting huge chunks of new code in.

Using a really really good debugger (like the one in VC++ 2008) is an absolute must here.

[frag.machine]

I second mh here: debug build all the way, incremental steps, avoid dropping large chunks of code at once (specially if it's not your code).

Also, the habit of refactoring code helps to isolate problems. Instead spreading the same code snippet across all the program, encapsulate it to a function. Instead laying 200 or more lines of hard-to-grasp-in-a-look code in a single sprint, break it in smaller functions with clear, significative names. If performance is a concern, you may later turn it in a inline function (though most of the cases the compiler itself takes care of optmize things to you). This way, you can easily enable/disable any calls to that code (or make it return a fixed value for test purposes).

BTW, I am not an "engine lord"; I just suffered enough thru years of coding and learned those things the hard way.

[mh]

[Spike]

if you want to make use of visual studio's fairly awesome debugging capabilities, make sure your project is set up for incremental compilation, function level compilation, and lots of other random edit+continue junk that is all over the place that keeps on randomly being disabled at random.
Once your project is set up, its basically just a case of 'select debug build, press f5'.
If you've got a debugger attached, and this applies for gdb or msvc, you probably want to run quake windowed. This is especially true for certain d3d api versions/options...
Once your program crashes, it'll take you to the line it crashed at.
If you actually found all the right options mentioned in the first paragraph, you can actually make your fix/changes, press alt+f10, then press f5, and it'll continue from where it crashed, but with your changes in place, without having to restart the entire damn thing! Seriously awesome!
There's no real reason to run it outside of a debugger, other than the fact that it runs a little slower (due to being a debug build). If your bottleneck is opengl then it won't really be visible anyway (just starting the ide first will, and the debugger loading debugging info from dlls).
f5: run
alt+f10: apply changes
f11: single step onto the next line (entering functions)
f10: single step onto the next line (don't step through called functions).
f9: toggle breakpoint on the current line
Really all you need.
FTE's svn has some extra minidump code in client/sys_win.c which can generate a dump file if it crashes on someone else's computer (its ifdefed - disabled in release builds). You can then open this file up on your computer and see the state of things as they were when they crashed on the other guy's computer. It can be quite useful, but it does require code changes to your engine in order to generate them (also requires external files to be unchanged from when the exe was written, the .pdb specifically, I think).

If you're debugging with gdb, make sure you compiled it with -g, preferably with -O0, and definitely not with -s (and not used the strip command either).
gdb --args myexe mycommandline
commands:
run: start running
next: single step (ignore function calls)
step: single step (step into functions)
cont: continue
info regi: register dump for debugging gcc bugs
bt: simple backtrace
bt full: backtrace that is actually useful
quit: give up and run away
break func: set a breakpoint on the first instruction of a function
break file line: set a breakpoint on a given file+line
watch variable: set a watchpoint on a variable
A simplistic aproach is to run it, let it crash, type bt full, then quit...
You can make a .gdbinit file containing commands to be run when gdb is started up, including 'set args=-window -game crashy -basedir myquakedir', 'file mybinary', 'run'.

If you're debugging on linux, I personally find that running it in valgrind is seriously awesome, although not without issues - specifically, ones caused by your graphics drivers being buggy shit. Use environment settings to configure indirect rendering and its much faster+sane, although you may loose certain GL extensions, so might impact debugging renderer changes.
Even if you think your code is fine, running it in valgrind often reveals some dirty little secrets. Just make sure they're *your* secrets before you start trying to fix them. :)

If you're using gcc to compile, there's an application called addr2line, which is a much faster alternative to what you currently do, and gives line numbers rather than just function names. Requires debugging info, the same as gdb does though.

[Spike]

I feel I should point out that what I said in my previous post relates purely to debugging. It does not relate well to writing new code.
Writing new code should never be written while in a debugger!
You should only use edit+continue stuff for small fixes and typos, or selective breakpoints perhaps.
But if you're writing new code, you should ensure that it is written correctly, before you start hacking at it from a debugger.
Debuggers are for debugging. Keep that in mind and your code will contain less bugs.
(I personally find msvc6 more usable than msvc2005, purely because msvc2005 messes up so much with preprocessor defines, and doesn't let you browse quickly on a per-function basis without it being part of some class... hello C! while msvc2003 has clumsy/vb default keyboard shortcut settings on top of that).

[r00k]

[mh]

[Downsider]

From what I've read, the PSP has a rudimentary debugger, though I've never needed to use it and thus never have, but since you seem to be having issues regarding your PSP engine, I thought I would let you know.

[frag.machine]

Don't shoot me if it's a stupid question, but... have anyone checked if there is some kind of PSP SDK for development on PC ? Let's say, an emulator where one can debug an application or something like that ?

[r00k]

[Baker]

[Baker]

[Baker]

gdb's debug [in Code::Blocks IDE] isn't quite as intuitive as Visual Studio but it isn't bad once you get used to it. -g + -ggdb as compiler options.

http://wiki.codeblocks.org/index.php?ti ... de::Blocks

To watch a global, right click on the Watch window much like MSVC and type in the name.