gdb-for-debugging

Diagnose process hangs, crashes, and deadlocks using GDB, strace, and /proc inspection.

3|1|Updated Apr 15, 2026
One-click install
npx skills add https://github.com/burningportra/agent-flywheel-plugin --skill gdb-for-debugging-burningportra
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: gdb-for-debugging
Source: https://github.com/burningportra/agent-flywheel-plugin/tree/main/skills/gdb-for-debugging
Command: npx skills add https://github.com/burningportra/agent-flywheel-plugin --skill gdb-for-debugging-burningportra

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Debugging live Linux processes is hard: GDB attach fails silently due to ptrace restrictions, backtraces from stripped binaries are unreadable, and intermittent race conditions vanish under a debugger. This Skill provides a structured, batch-mode workflow for diagnosing hangs, segfaults, deadlocks, and memory corruption in running processes without guesswork. ## Core Features & Use Cases - Hang and Spin-Loop Diagnosis: Identify hot threads with ps and strace, then capture full thread backtraces with GDB batch mode to pinpoint accept loops, futex spins, and lock contention. - Crash and Core Dump Analysis: Capture register state, backtraces, and faulting addresses from segfaults, including stripped-binary symbol recovery via addr2line, readelf, and objdump. - Advanced Tooling Integration: Reverse debugging with rr (reverse watchpoints to find memory corruption), ASAN/TSAN sanitizer integration, deadlock detection via mutex wait-for graphs, and GDB Python scripting for automated thread categorization. - Use Case: A Rust HTTP server pegs a CPU core and stops responding to requests. Follow the triage loop to find the hot thread, strace it to reveal an accept4/EAGAIN spin loop, and capture a GDB backtrace pointing to the exact missing epoll call. ## Quick Start Ask the agent to diagnose why process PID 12345 is stuck at 100% CPU using the gdb-for-debugging workflow.

Frequently Asked Questions about gdb-for-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I attach GDB to a running process and get a backtrace?

First relax ptrace with 'echo 0 > /proc/sys/kernel/yama/ptrace_scope', then run 'gdb --batch -ex "thread apply all bt" -p PID'. Batch mode captures all thread backtraces non-interactively and is safe to pipe to a file.

Why does GDB attach fail with 'Operation not permitted'?

Modern Linux defaults yama ptrace_scope to 1, which blocks non-parent processes from attaching. Set it to 0 via /proc/sys/kernel/yama/ptrace_scope before attaching, and restore it afterward on production machines.

How do I find which thread is causing 100% CPU usage?

Run 'ps -Lp PID -o tid,pcpu --sort=-pcpu' to find the hottest TID, then strace that TID to see its syscall pattern and capture a GDB backtrace. A tight accept4/EAGAIN or futex loop reveals the spin location.

When should I use rr instead of GDB for debugging?

Use rr for race conditions, heisenbugs, and memory corruption where you need to find who wrote a bad value. rr records execution deterministically and supports reverse-continue with watchpoints; GDB attach is better for live production processes.

How do I debug a segfault in a stripped binary with no symbols?

Recover the binary from /proc/PID/exe, then use addr2line, readelf, or objdump to map crash addresses to the nearest symbols. Rust binaries often retain dynamic symbols that readelf --dyn-syms can reveal.

Can GDB detect deadlocks between threads automatically?

Yes, via GDB Python scripting that builds a mutex wait-for graph: extract futex addresses from blocked threads, map locks to their holders, and run cycle detection. A cycle in the graph is a proven deadlock.