Segfaults mean a process touched memory it shouldn't. For most people it's not your bug to debug — it's the environment: bad libs, missing resources, or stack limits. Here's the triage order.
The binary was built against different library versions than it runs with (or a CPU without the expected extensions). ldd <bin> and comparing against a working host finds it.
Deep recursion (and some JVM/Postgres setups) exceed the default 8MB stack: ulimit -s shows it. Raising it fixes 'segfault only under heavy work' patterns.
For software you build: null derefs, bad pointers, array overruns. gdb + core dump or ASAN builds localize them; the core pattern (ulimit -c unlimited) captures the evidence.
ldd <binary> 2>&1 | grep -i 'not found' ; ulimit -s ; uname -mulimit -c unlimited ; gdb -batch -ex run -ex bt <binary> 2>&1 | tail -15ulimit -s unlimited && <binary> # or raise it in systemd: LimitSTACK=16M# gcc -fsanitize=address -g ... — ASAN points at the exact bad access instead of just SIGSEGVSegfault on one host but not another is almost always libs or CPU features, not randomness. Containers: check the image's glibc vs the binary's build target (debian vs alpine musl is the #1 shipped-binary segfault).
No — triage the environment first: ldd for missing libs, ulimit for limits, host arch. If the environment is sane, capture the core and file a report with the backtrace; don't hand-fix vendor binaries.
Most distros pipe cores to systemd-coredump or apport now: coredumpctl list shows them (coredumpctl gdb <pid> to inspect). ulimit -c unlimited re-enables classic core dumps where supported.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.