Debugging under Linux
This article is an orphan, meaning that few or no articles link to it.
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.)
To do: 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="$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.
To do: Perhaps add a few pointers to