Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
howto:gdb [2010/04/14 17:21] – digitalmanhowto:gdb [2024/11/04 02:56] (current) – [Debug Synchronet for *nix using GDB] Ad bug character to title digital man
Line 1: Line 1:
-====== Debug Synchronet for *nix using GDB ======+====== 🐛 Debug Synchronet for *nix using GDB ======
  
 You can either run Synchronet (''sbbs'') from the GNU debugger (''gdb''), or you You can either run Synchronet (''sbbs'') from the GNU debugger (''gdb''), or you
Line 9: Line 9:
 For the debugger output to be most useful, you need to execute a //debug// build of Synchronet. That means that the executable files or symlinks in your ''[[dir:exec]]'' directory should be //debug// and not //release// builds. If you run ''ldd'' on your ''[[dir:exec]]/sbbs'' file and it is dependent on libraries in your Synchronet ''*.lib.release'' directory, then you are running a //release// build of sbbs. You need to build withOUT the ''RELEASE=1'' gmake command-line option to build debug binaries and you may need to copy or update the symlinks in your ''[[dir:exec]]'' directory to use the //debug// binaries. For the debugger output to be most useful, you need to execute a //debug// build of Synchronet. That means that the executable files or symlinks in your ''[[dir:exec]]'' directory should be //debug// and not //release// builds. If you run ''ldd'' on your ''[[dir:exec]]/sbbs'' file and it is dependent on libraries in your Synchronet ''*.lib.release'' directory, then you are running a //release// build of sbbs. You need to build withOUT the ''RELEASE=1'' gmake command-line option to build debug binaries and you may need to copy or update the symlinks in your ''[[dir:exec]]'' directory to use the //debug// binaries.
  
 +Backtraces and other debug output from //release// builds can still be useful, so if you have a core file from a //release// build crash, please continue with the debug process using the //release// build. If more details are needed  (e.g. function argument values) to determine the root-cause of the problem, then a similar core from a crash of a //debug// build will be needed. But it's fine to start with a //release// build if that's all you have.
 ===== Core File ===== ===== Core File =====
  
Line 19: Line 20:
 You can run ''ulimit -c'' to check if core file generation is enabled for the 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  current user profile (0 = disabled, non-zero or "unlimited" = enabled). An 
-"unlimited" core file size is the preferred setting. If your system is +"unlimited" core file size is the preferred setting.
-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 +On Debian Linux (at least), you can enable unlimited core file generation as the default for 
-lines in your ''/etc/sysctl.conf'' file can be helpful:+all (non-root) users by adding the following line to ''/etc/security/limits.conf'' file: 
 +<file> 
 +*               soft    core            unlimited 
 +</file> 
 + 
 +If you're running sbbs daemonzied (e.g. as a *nix service), you may need to edit your service 
 +start up script (e.g. ''/etc/init.d/sbbs'') to set the core limit to //unlimited//: 
 +  ulimit -c unlimited 
 +   
 +Of in the ''[Service]'' section of your ''/lib/systemd/system/sbbs.service'' file: 
 +  LimitCORE=infinity 
 +   
 +:!: **Linux Sysops**:\\ 
 +To help locate sbbs crash core files, adding the following lines in your ''/etc/sysctl.conf'' or ''/etc/sysctl.d/sysctl.local.conf'' file can be helpful:
  
   # Controls whether core dumps will append the PID to the core filename.   # Controls whether core dumps will append the PID to the core filename.
Line 33: Line 45:
 This will place core files with the name ''core.sbbs.####'' in the ''/tmp'' directory This will place core files with the name ''core.sbbs.####'' in the ''/tmp'' directory
 instead of ''core.####'' in the current directory (typically ''/sbbs/ctrl''). instead of ''core.####'' in the current directory (typically ''/sbbs/ctrl'').
 +To reload the modified sysctl configuration files, run
 +  $ /sbin/sysctl --system
 +
 +Also, if you're using the ''setuid'' feature of sbbs (e.g. starts as //root// but changes to a different user after binding ports), then you may need to add the following line to your ''/etc/sysctl.conf'' file:
 +  fs.suid_dumpable = 2
 +  
 +You can also set ''suid_dumpable'' immediately and temporarily with the following command:
 +  $ echo 2 > /proc/sys/fs/suid_dumpable
 +  
  
 ===== Debugging ===== ===== Debugging =====
Line 40: Line 61:
 or (if debugging with a core file): or (if debugging with a core file):
   # gdb /sbbs/exec/sbbs /tmp/core.sbbs.####   # gdb /sbbs/exec/sbbs /tmp/core.sbbs.####
 +or (if attaching to an existing running instance, reading the PID from ''/var/run/sbbs.pid''):
 +  # gdb /sbbs/exec/sbbs <pid>
 +or (if attaching to an existing running instance, using ''pidof'' to determine the PID):
 +  # gdb -p $(pidof sbbs)
  
-B. Run Synchronet (if no core file used):+B. Run Synchronet non-daemonized (if no core file used):
   (gdb) run -nd   (gdb) run -nd
  
 C. After segfault or other crash (or when using a core), display back-trace: C. After segfault or other crash (or when using a core), display back-trace:
   (gdb) bt   (gdb) bt
 +or (if more details are needed):
 +  (gdb) bt full
  
 D. If (and only if) the last line of the output looks like this: D. If (and only if) the last line of the output looks like this:
Line 53: Line 80:
  
 E. Copy and paste in e-mail to rob[at]synchro[dot]net or post in one of the Synchronet [[support|discussion groups]]. E. Copy and paste in e-mail to rob[at]synchro[dot]net or post in one of the Synchronet [[support|discussion groups]].
 +
 +**TIP:**\\
 +To run Synchronet (non-daemonized) directly from the GNU debugger without having to type "run" at a ''(gdb)'' prompt:
 +  # gdb -ex run --args sbbs -nd
 +
 +==== Root Access ====
 +
 +If the ''sbbs'' process was started as root, you may need root privileges to attached with ''gdb'':
 +
 +  Attaching to process 21848
 +  ptrace: Operation not permitted.
 +  (gdb)
 +  
 +If you get this error, try attaching again as root (e.g. run with ''sudo gdb'').
 +
 +==== Handling SIGPIPE ====
 +
 +When debugging a //running// ''sbbs'' instance, the "broken pipe" signal (''SIGPIPE'') may normally occur (e.g. when a TCP socket is disconnected) and these signals may cause unwanted breaks into GDB (temporarily stopping sbbs and requiring a ''g'' command to continue). To disable this behavior, at the ''(gdb)'' prompt, type:
 +  (gdb) handle SIGPIPE nostop noprint pass
 +  
 +Alternatively, you can add the following line to your ''~/.gdbinit'' file or ''/etc/gdb/gdbinit'':
 +  handle SIGPIPE nostop noprint pass
 +  
 +===== Thread Snapshot =====
 +
 +To attach to a running sbbs process and quickly collect a snapshot of backtraces from all running threads (remember, obtain root privileges first, e.g. with ''sudo'', if necessary):
 +  $ gdb -p $(pidof sbbs) -batch -ex "thread apply all bt" -ex quit > sbbs_threads.txt
  
 ===== See Also ===== ===== See Also =====
-  * [[:howto:|howto index]]+  * [[:howto:|How-To index]] 
 +  * [[https://wiki.debian.org/HowToGetABacktrace]]
  
 {{tag>debug unix linux gdb}} {{tag>debug unix linux gdb}}
  

Trace: