Debugging under Linux: Difference between revisions
TomEdwards (talk | contribs) m (→Memory dumps) |
Thunder4ik (talk | contribs) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= | {{Multiple issues| | ||
{{Dead end|date=January 2024}} | |||
{{orphan}} | |||
}} | |||
== Memory dumps == | == Memory dumps == | ||
Linux | 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: | |||
ulimit -c 2000 | ulimit -c 2000 | ||
2000 is in | 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 <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. | |||
To poke around more, you can launch <code>[http://sourceware.org/gdb/ gdb]</code> on the coredump with this command: | |||
gdb ./srcds_i686 core | |||
(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.) | |||
== Runtime debugging == | |||
{{TODO|Check if this actually works}} | |||
When the server | 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" | |||
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. | |||
{{TODO|Perhaps add a few pointers to <code>gdb</code> tutorials}} | |||
[[Category:Programming]] | [[Category:Programming]] | ||
[[Category:Linux]] | [[Category:Linux]] | ||
Latest revision as of 08:52, 21 January 2024
links to other VDC articles. Please help improve this article by adding links that are relevant to the context within the existing text. January 2024
You can help by
adding links to this article from other relevant articles. 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
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.
gdb tutorials