gdb: Usage, Options & Common CI Errors
gdb inspects, controls, and post-mortems native programs and core dumps.
gdb in CI is mostly used non-interactively: run a crashing test under it and print a backtrace, or open a core dump. The headline container failure is "ptrace: Operation not permitted", a missing capability rather than a gdb bug.
What it does
gdb is the GNU debugger. It runs a program under its control, sets breakpoints, inspects memory and variables, and produces stack backtraces - live or from a core dump. For CI it is driven in batch mode to symbolize crashes automatically.
Common usage
gdb --batch -ex run -ex bt --args ./app arg1
gdb -batch -ex bt ./app core # post-mortem a core dump
gdb --batch -ex 'thread apply all bt' ./app core
gdb -p <pid> -batch -ex bt # attach to a process
ulimit -c unlimited # enable core dumps firstOptions
| Flag | What it does |
|---|---|
| --batch | Run commands then exit (non-interactive) |
| -ex <cmd> | Execute a gdb command |
| --args <prog> ... | Program plus its arguments |
| <prog> <core> | Load a program and core dump |
| -p <pid> | Attach to a running process |
Common errors in CI
"ptrace: Operation not permitted" in a container means the kernel blocks ptrace - run with --cap-add=SYS_PTRACE (and often --security-opt seccomp=unconfined), or set /proc/sys/kernel/yama/ptrace_scope=0. "No stack" / "??" in backtraces means no debug info - build with -g and do not strip the binary you debug. Core dumps need ulimit -c unlimited AND a writable core_pattern; many CI containers pipe cores to a host handler, so the core never lands in the workspace.