Debugging under Linux

Memory dumps

The Linux kernel creates core dumps of misbehaving programs automatically (unless the programs handle their crashing themselves; srcds doesn't). However, on many systems, this behavior is disabled by default for the sake of security (an attacker might force many programs to dump core, filling up your hard drives).

When you launch the srcds_run script with the -debug flag, one of the first things the script will attempt is to lift the size limit of a core dump to 2000 KiB if it is set to zero. Should this fail (or if you need a larger dump), you can try overriding the limit by issuing this command before launching the server:

ulimit -c 2000

This lifts the core size limit to 2000 KiB -- replace as needed.

When the server crashes, a file whose name is (or begins with) "core" shall appear in the current directory. If you have used the -debug flag, the srcds_run script has already generated a file named debug.log which contains potentially useful information such as a backtrace.

To poke around more, you can launch gdb on the coredump with this command:

gdb ./srcds_i686 core

(If you have used a different binary than srcds_i686, make sure you supply the correct name, or gdb will be confused.)

Runtime debugging

Todo: Check if this actually works

When you have found a stable method to reproduce a bug but the coredump isn't sufficient, you may wish to launch the server within gdb and try a few things while the server is only half-dead. To do this, you'll need to modify the srcds_run script, replacing the line

HL_CMD="$HL $PARAMS"

with

HL_CMD="$GDB --args $HL $PARAMS"

This will prepare the server for launch through gdb; you will have to type run to actually start it. Note that the server will be pretty slow, so don't do this on a production system.

Todo: Perhaps add a few pointers to gdb tutorials