Difference between revisions of "Debugging under Linux"

From Valve Developer Community
Jump to: navigation, search
m (Memory dumps)
Line 1: Line 1:
== Runtime debugging ==
+
== 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 <code>srcds_run</code> script with the <code>-debug</code> 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:
  
TODO!
+
ulimit -c 2000
  
== Memory dumps ==
+
This lifts the core size limit to 2000 KiB -- replace as needed.
  
Linux memory dumps are created and handled by '''coredump'''.
+
When the server crashes, a file whose name is (or begins with) "core" shall appear in the current directory. If you have used the <code>-debug</code> flag, the <code>srcds_run</code> script has already generated a file named <code>debug.log</code> which contains potentially useful information such as a backtrace.
  
On many GNU/Linux distribution it is disabled by default, for security reasons. A simple command can be change this limitation :
+
To poke around more, you can launch <code>[http://sourceware.org/gdb/ gdb]</code> on the coredump with this command:
  
  ulimit -c 2000
+
  gdb ./srcds_i686 core
  
2000 is in kilobytes. The command must be applied before the launch of the server.
+
(If you have used a different binary than <code>srcds_i686</code>, make sure you supply the correct name, or <code>gdb</code> will be confused.)
  
When you add -debug parameter to srcds_run the ulimit is called with 2000 kilo bytes (like my example). {{todo|Does this franglais mean that <code>-debug</code> allows you to skip the ulimit command?}}
+
== Runtime debugging ==
 +
{{todo|Check if this actually works}}
  
When the server crashes, a new file appear, called "core". You can launch [http://sourceware.org/gdb/ gdb] on this coredump with this command:
+
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 <code>gdb</code> 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"
  
gdm ./srcds_i686 core
+
This will prepare the server for launch through <code>gdb</code>; you will have to type <code>run</code> to actually start it. Note that the server will be pretty slow, so don't do this on a production system.
  
(Replace srcds_i686 by the executable really used on your system.)
+
{{todo|Perhaps add a few pointers to <code>gdb</code> tutorials}}
  
 
[[Category:Programming]]
 
[[Category:Programming]]
 
[[Category:Linux]]
 
[[Category:Linux]]

Revision as of 22:57, 5 July 2008

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

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="$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.

To do: Perhaps add a few pointers to gdb tutorials