Debian测试服务器应用段错误排查：如何获取堆栈跟踪？

Hey there! Sorry to hear you're stuck with those annoying segmentation faults on your Debian test server—they’re definitely a pain, but capturing a stack trace will help you pinpoint exactly where things are going wrong. Here are some straightforward methods to get that critical info:

1. Debug directly with GDB #

GDB is your go-to tool for live debugging and analyzing crashes.

Option A: Run your app inside GDB #

• Launch your application with GDB attached:

  gdb ./your-application-binary
  

• Once in the GDB prompt, start your app with run
• Perform the login/register action that triggers the segfault
• When the crash happens, type bt (short for backtrace) to get the full stack trace. For even more detail (like local variables), use bt full

Option B: Attach GDB to a running process #

If your app is already up and running:

• Find its process ID (PID) first:

  ps aux | grep your-application-name
  

• Attach GDB to the process:

  gdb ./your-application-binary <pid>
  

• Type continue to let the app resume normal operation
• Trigger the segfault, then use bt or bt full to view the stack trace

2. Capture a core dump for post-crash analysis #

A core dump is a snapshot of your app’s memory at the time of the crash, which you can analyze later with GDB.

Step 1: Enable core dumps #

• First check if core dumps are enabled:

  ulimit -c
  

  If the output is 0, they’re disabled.
• Temporarily enable unlimited core dumps for your current session:

  ulimit -c unlimited
  

• To enable them permanently across reboots, edit /etc/security/limits.conf and add these lines:

  * soft core unlimited
  * hard core unlimited
  

• Make sure the kernel is configured to save core files. Check the pattern with:

  cat /proc/sys/kernel/core_pattern
  

  The default is usually core or core.%p (which includes the PID in the filename).

Step 2: Analyze the core dump #

• Trigger the segfault—you’ll see a core file appear in your app’s working directory (or the path defined by core_pattern)
• Load the core file into GDB:

  gdb ./your-application-binary core
  

• Again, use bt or bt full to get the stack trace

3. Configure systemd to capture core dumps (if your app runs as a service) #

If your application is managed by systemd, you can set it up to automatically capture core dumps on crash:

• Edit your app’s systemd service file (e.g., /etc/systemd/system/your-app.service)
• Add this line under the [Service] section:

  LimitCORE=infinity
  

• Reload systemd and restart your service:

  systemctl daemon-reload
  systemctl restart your-app.service
  

• After a crash, core dumps are usually stored in /var/lib/systemd/coredump/. You can analyze them with GDB just like regular core files.

Important Note: Debug Symbols #

For meaningful stack traces, your application needs to be compiled with debug symbols. If you built the app yourself, add the -g flag to your compiler command (e.g., gcc -g -o app app.c) and avoid aggressive optimizations like -O2 (they can warp stack trace information). If you’re using a pre-built binary, look for a corresponding debug package in Debian’s repos (usually named <package-name>-dbg) and install it.

内容的提问来源于stack exchange，提问作者Detilium