查段错误需日志线索、core文件、调用栈三者联动：journalctl定位崩溃时间/PID/信号，coredumpctl提取core并确认调试信息，gdb回溯调用栈定位源码行，再结合前后日志分析OOM、权限、内核oops等根因。
查段错误不能只盯着 journalctl 一条命令，它只是入口，真正要定位问题得靠日志线索+core 文件+调用栈三者联动。journalctl 的作用是快速锁定崩溃发生的时间、进程和信号类型，而不是直接告诉你哪行代码错了。
用 journalctl 快速筛出 segfault 记录
systemd 默认接管所有服务的崩溃记录，所以不用手动找 core 文件，先从日志里把事件捞出来：
- 查指定服务最近崩溃：`journalctl -u myapp.service --no-pager -n 100 | grep -i "segfault\|core.*dump\|exited.*139\|signal.*11"`
- 全局扫描近期可疑崩溃：`journalctl -b -p err | grep -E "(segfault|SIGSEGV|dumped core|code 139)" | tail -n 10`
- 重点抓 PID 和时间戳：比如日志中出现 `systemd-coredump[1234]: Process 5678 (myapp) of user 1000 dumped core`，其中 5678 就是关键 PID，后续分析全靠它
确认 core 是否被捕获并提取信息
只要 journalctl 显示了 systemd-coredump 条目，说明 core 已存档，路径由 kernel.core_pattern 决定，默认在 `/var/lib/systemd/coredump/`：
- 列出所有已归档 core：
coredumpctl list，按时间倒序，最新一条最相关 - 按程序名过滤：
coredumpctl list myapp，看 size 是否合理（几十 MB 正常，几 KB 可能截断） - 查详细元数据：
coredumpctl info myapp，确认信号类型（如 SIGSEGV）、可执行路径、是否含调试符号、UID 和生成时间
用 gdb 回溯调用栈定位代码位置
core 文件本身不带源码，但配合带调试信息的二进制文件，gdb 能精准指出崩溃点：
- 一键调试（推荐）：
coredumpctl debug myapp，自动匹配 binary 和 core - 手动加载：
gdb /usr/bin/myapp /var/lib/systemd/coredump/core.myapp.1000.…… - 进 gdb 后立刻执行：
bt（backtrace），顶部第一行就是崩溃发生的函数与源码行号 - 若显示 ?? 或地址而非函数名，说明缺少调试符号——需重装
myapp-dbg包或编译时加-g
结合上下文日志判断深层原因
gdb 告诉你“崩在哪”，journalctl 才能解释“为什么崩”。必须回到崩溃时间点前后查环境线索：
- 用 coredumpctl info 中的时间，向前查 5 分钟日志：
journalctl --since "2026-07-07 20:45:00" --until "2026-07-07 20:50:00" -o short-precise - 重点关注：Out of memory（OOM killer 杀进程）、timeout（启动超时导致状态异常）、permission denied（配置文件权限错）、Failed to load module（依赖缺失）
- 检查内核是否干预：追加
journalctl -k --since "2026-07-07 20:45:00"看是否有 oops、general protection fault 等内核级报错
