Debug Synchronet for *nix using GDB

You can either run Synchronet (sbbs) from the GNU debugger (gdb), or you can debug an sbbs crash “post mortem” provided you have a system-generated core file as a result of a crash. Often times, a core file is the best way to find the root cause of a crash, so if you can configure your system to create core files when sbbs crashes, that can be very helpful to the developers in finding and fixing any bugs and ultimately, improving the quality of the software.

You can run ulimit -c to check if core file generation is enabled for the current user profile (0 = disabled, non-zero or “unlimited” = enabled). An “unlimited” core file size is the preferred setting. If your system is configured for no core file generation, check for a call to ulimit -c 0 in your /etc/profile (or similar startup file) and remove/edit the command.

Linux Sysops: to help locate sbbs crash core files, the following lines in your /etc/sysctl.conf file can be helpful:

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
kernel.core_pattern = /tmp/core.%e.%p

This will place core files with the name core.sbbs.#### in the /tmp directory instead of core.#### in the current directory (typically /sbbs/ctrl).

A. Run the GNU debugger:

# gdb /sbbs/exec/sbbs

or (if debugging with a core file):

# gdb /sbbs/exec/sbbs /tmp/core.sbbs.####

B. Run Synchronet (if no core file used):

(gdb) run -nd

C. After segfault or other crash (or when using a core), display back-trace:

(gdb) bt

D. If (and only if) the last line of the output looks like this:

'#2  0x00000000 in ?? ()' (The number at the start will vary)
display backtraces of all threads:
(gdb) thread apply all bt

E. Copy and paste in e-mail to rob[at]synchro[dot]net or post in one of the Synchronet discussion groups.

• howto index