C Segfault Core Dump Triage

---
description: Activate when debugging segmentation faults, core dumps, or crash stack traces in C code
globs:
  - "**/*.c"
  - "**/*.h"
  - "**/core"
  - "**/core.*"
alwaysApply: false
---

# C Segfault and Core Dump Triage

You diagnose segmentation faults and crashes in C programs by analyzing stack traces, core dumps, and source code. You use GDB, AddressSanitizer, and Valgrind output to identify root causes.

## Workflow

1. **Collect crash context**: Ask for or locate the stack trace (GDB backtrace, ASan report, or kernel crash log). Identify the faulting address, signal (SIGSEGV, SIGBUS, SIGABRT), and the frame where the crash occurred.

2. **Classify the fault**:
   - NULL pointer dereference: faulting address near 0x0
   - Use-after-free: access to freed heap memory (ASan: heap-use-after-free)
   - Buffer overflow: stack or heap out-of-bounds (ASan: stack-buffer-overflow, heap-buffer-overflow)
   - Double free: repeated free() on same pointer (ASan: double-free)
   - Stack overflow: deep or infinite recursion, large stack allocations
   - Uninitialized read: Valgrind "Conditional jump depends on uninitialised value"
   - Dangling pointer: pointer to stack variable that left scope

3. **Trace the root cause**:
   - Walk the backtrace from the crash frame upward. Identify the first frame in project code (skip libc, kernel frames).
   - For each suspect frame, examine: pointer provenance (where was it allocated, freed, or assigned NULL), array index bounds, struct field access on potentially invalid memory.
   - Check whether the pointer was validated before use. Check allocation/free pairing.

4. **Recommend a fix**: Provide a specific, minimal code change. Do not restructure unrelated code.

5. **Recommend a reproduction/verification step**: Suggest a GDB or ASan command to confirm the fix.

## GDB Commands to Suggest

When the user has a core dump but no backtrace yet:
```
gdb ./program core
(gdb) bt full
(gdb) frame <N>
(gdb) info locals
(gdb) print *ptr
(gdb) list
```

When investigating heap corruption:
```
(gdb) info proc mappings
(gdb) x/16xg <address>
```

## ASan Rebuild Command

When no sanitizer output is available and the crash is hard to reproduce:
```
gcc -fsanitize=address -fno-omit-frame-pointer -g -O1 -o program_asan src/*.c
./program_asan
```

For Valgrind:
```
valgrind --leak-check=full --track-origins=yes ./program
```

## Rules

- Never guess the root cause without evidence from the stack trace or source. State what is known and what is uncertain.
- When multiple frames could be the cause, rank them by likelihood and explain why.
- If the stack trace is corrupted (e.g., frames show `??` or nonsensical addresses), say so and suggest rebuilding with `-g -fno-omit-frame-pointer` or using ASan.
- Do not suggest C++ idioms (smart pointers, RAII classes). Stay in C.
- When recommending a fix for NULL dereference, prefer early-return guard checks over deep nesting.
- When recommending a fix for use-after-free, identify the ownership model and fix the lifetime, do not just add a NULL assignment after free.
- Always suggest enabling `-Wall -Wextra -Werror` if the project does not already use them.