上下文：我刚进入公司，分配到了大数据存储组里，自研了hdfs，名为yhdfs，其底层是c++写的，用...

Question

上下文：我刚进入公司，分配到了大数据存储组里，自研了hdfs，名为yhdfs，其底层是c++写的，用了ufs的一些存储，但是自身应该也写了一些sdk，然后需要实现hadoop客户端的一些接口，所以也涉及了一些java。我主要的工作是巡检集群是否正常工作，是否有一些异常的报错。
我要研究一下，core-file （因为要找到具体是哪里的代码出错了），你首先我给我介绍一下core-file吧，尽量全面。

Answer 1

好的！下面给你一份尽量全面、工程一线可用的 core file（核心转储）介绍，重点偏向 Linux 上的 C/C++ 进程（你们的 yhdfs C++ 进程）以及 JNI/Java 场景（Hadoop 客户端接口）。

什么是 core file

当进程因为严重错误收到会触发“产生核心转储”的信号时（常见如 SIGSEGV、SIGABRT、SIGBUS、SIGILL、SIGFPE、SIGTRAP），内核把当时的进程内存快照、寄存器、线程栈、映射的共享库信息等写到一个文件里，这个文件就是 core。
它能让你在事后用调试器还原进程当时的状态，定位崩溃位置与调用栈，即使程序已经退出。

core 里包含什么

可执行文件与各共享库的映射信息（地址、路径、Build ID）
所有线程的寄存器与调用栈（含线程名）
选定的内存段内容（代码段、栈、部分堆/匿名映射等）
进程基本信息与环境变量/命令行（可能含敏感信息）
（ELF note 区）诸如 NT_PRSTATUS / NT_PRPSINFO / NT_AUXV / .note.gnu.build-id 等调试所需元数据

core 何时会（不会）生成

会：收到会 core 的信号，且 RLIMIT_CORE（ulimit）允许、核心生成未被拦截。
不会：进程被 SIGKILL（如 OOM killer）直接杀死、ulimit 为 0、系统配置将 core 重定向到收集服务但被丢弃、容器/权限限制、setuid 程序默认禁止等。

开启与存放位置

临时开启（当前 shell / 进程）

bash
ulimit -c unlimited           # 允许无限大小 core
# 验证
ulimit -a | grep 'core file size'

永久/服务级（systemd 管理的服务）
在 unit 文件里：

LimitCORE=infinity

并重启服务。

core 文件名与路径

传统：/proc/sys/kernel/core_pattern 决定文件名/路径，例如：
```
bash
sudo sysctl -w kernel.core_pattern='/var/core/core.%e.%p.%t'
```
%e 程序名，%p PID，%t 时间戳。
若 core_pattern 以 | 开头（如 |/usr/lib/systemd/systemd-coredump），说明 core 被管道到收集器（如 systemd-coredump）。此时文件一般在 /var/lib/systemd/coredump/，用 coredumpctl 取用。

setuid 程序与安全

bash
# 2 = 允许 setuid 程序的 core，写到安全目录
sudo sysctl -w fs.suid_dumpable=2

容器 / K8s 注意

容器需要 --ulimit core=-1、适当的 SYS_PTRACE/CAP_SYS_RESOURCE 能力、以及主机层 core_pattern 配置。
systemd-coredump 常在宿主机上汇聚；想把 core 落到卷里需额外配置。

如何触发/收集一个 core（用于验证流水线）

让程序自己崩溃：插入 *(int*)0=0; 或 abort();

给正在运行的进程生成 core（不中断/短暂停顿）：

bash
gcore -o mycore <PID>       # gdb/psmisc 提供的工具
# 或在 gdb 中：
gdb -p <PID>
(gdb) generate-core-file /tmp/core.myapp
(gdb) detach; quit

分析 core 的常用流程（C/C++）

A. systemd-coredump 场景（推荐）

bash
# 列表/筛选
coredumpctl list mybinary
# 直接进 gdb（自动匹配可执行文件/库）
coredumpctl gdb <PID|COREDUMP_ID>

B. 传统 core 文件

bash
# 你需要：core 文件 + 产生 core 的同版本可执行文件/共享库 + 符号文件
gdb /path/to/mybinary /path/to/core
(gdb) set pagination off
(gdb) info proc cmdline
(gdb) info sharedlibrary
(gdb) thread apply all bt full          # 所有线程完整栈
(gdb) f 0; info registers               # 观察崩溃现场寄存器
(gdb) disassemble /m $pc-32, $pc+64     # 汇编+源码对照
(gdb) p someVar                         # 打印变量

关键要点

符号（symbols）：编译时加 -g（DWARF），发布包可剥离符号并单独保存 .debug 文件；分析时通过 build-id 或 debuglink 自动匹配。没有符号也能定位到函数/偏移，但源码级定位困难。
优化影响：-O2/内联会让栈看起来“跳跃”；必要时用 -g3 -fno-omit-frame-pointer 改善可读性。
C++ 名字重整：gdb 会自动还原；也可 c++filt。
地址到行号：若只有地址，addr2line -e mybinary 0x7f...。
多线程：thread apply all bt，关注持锁/等待线程。
崩溃类型：从 info signal、dmesg | tail（内核“segfault at … ip …”）确认是越界、非法指令还是除零等。

Java / JNI / Hadoop 相关

在你们场景里，Java 客户端通过 JNI 调用 yhdfs C++ SDK，很容易出现“Java 进程因 native 崩溃产生 core”的情况。

HotSpot 会生成：
- hs_err_pid<pid>.log（极其重要，纯文本，含崩溃线程、寄存器、堆栈、已加载库、JVM 参数）
- 在 ulimit -c 允许时，还会把整个进程 core 出来

常用选项：

text
-XX:+CreateCoredumpOnCrash            # JVM 崩溃额外生成 core
-XX:ErrorFile=/path/hs_err_pid%p.log  # 定位 hs_err 日志位置
-XX:OnError="gcore %p; /bin/sleep 5"  # 崩溃瞬间执行命令（如再打一个 core）
-XX:+HeapDumpOnOutOfMemoryError       # OOM 时生成 heap dump（不是 core）
-XX:HeapDumpPath=/path

分析 Java 进程的 core（看 native/JNI 与 Java 两侧）：
1. 先读 hs_err_pid*.log 把高概率问题（哪个线程、哪条 JNI 调用）锁定；
2. 用 jhsdb（JDK 自带）直接打开 core：
```
bash
jhsdb hsdb --core /path/core --exe /path/java
# 或更轻量的
jhsdb jstack --core /path/core --exe /path/java
jhsdb jmap   --core /path/core --exe /path/java
```
  这样能看到 Java 层栈 + native 桥接点，再跳到 gdb 看 C++ 具体函数。
3. 直接 gdb 打开：
```
bash
gdb /path/java /path/core
(gdb) thread apply all bt
(gdb) where
# 找到落入 libyhdfs.so / libhdfs.so / libjvm.so 的帧
```

你们组可落地的巡检/排障清单

启用与收集

确认线上服务（如 yhdfs 的 Namenode/DataNode/SDK 守护进程）LimitCORE=infinity
统一 core_pattern 到固定目录或使用 systemd-coredump，并设置保留/清理策略
为所有产物建立符号服务器/仓库（保留 .debug 或带行号的映射，按 build-id 存储）
容器化部署：设置 ulimit、挂载 core 目录、必要 capabilities

发生崩溃后

用 coredumpctl info/gdb 或 gdb <exe> <core> 打开

thread apply all bt full 保存现场（脚本化）：

bash
gdb -q /path/exe /path/core -batch \
  -ex 'set pagination off' \
  -ex 'info sharedlibrary' \
  -ex 'thread apply all bt full' \
  -ex 'quit' | tee backtrace.txt

确认崩溃信号、故障地址、访问的内存（空指针/越界/已释放）
对可疑地址用 addr2line/disassemble /m 定位源码行
检查与崩溃线程相关的锁/等待（死锁/竞态）
结合日志时间线（崩溃前后 WARN/ERROR），以及 dmesg 里的 segfault 记录

Java 客户端/JNI

收集 hs_err_pid*.log、heap dump（若 OOM）
jhsdb jstack/jmap + gdb 对应帧，确认 JNI 参数/内存所有权、线程 attach/detach 是否规范
检查 native 层是否混用不同版本的 libprotobuf/libssl 等共享库（符号冲突很常见）

常见“为什么没产 core”的坑

ulimit -c 0（服务或容器里没改到位）
core_pattern 指向了收集器但磁盘配额/保留策略把它清理掉了
以 SIGKILL 结束（如 OOM killer），不会有 core
进程是 setuid 且 fs.suid_dumpable 未配置
不同机器/镜像的二进制与符号不匹配，导致 gdb 无法还原到源码

辅助工具与技巧

eu-stack / eu-unstrip（elfutils），readelf、objdump -Cd --source
lldb --core core --file exe（偏 BSD/macOS/也支持 Linux）
线上快速抓取：pstack <pid>（仅活跃进程），perf report（性能问题）
ASan/UBSan：若开启，崩溃前通常会有更可读的报告；与 core 共用更佳

如果你愿意，我可以给你们 yhdfs 的服务/容器写一份标准化 core 采集与分析 SOP（systemd unit、core_pattern、清理策略、gdb 批处理脚本、jhsdb 用法），让巡检时一键收集关键信息。

Answer 2

很好，这些都是一线排障会遇到的真实疑惑。下面我按“为什么会有 core、怎么配置、怎么从一个 core 追到进程/容器/日志、以及你提到的底层细节与 C++/JNI 常见坑”来讲，尽量把每一步做成可执行的清单。

1) 为什么会有 core，它从哪儿来？

触发机制：进程在收到会触发转储的信号（常见：SIGSEGV 访问非法内存、SIGABRT 主动 abort()、SIGILL 非法指令、SIGBUS 总线错误、SIGFPE 除零等）时，内核把当时的进程状态写成一个“核心转储文件”（core）。
是不是 JNI/SDK 导致？
可能，但不一定。只要进程里的任何本地代码（包括你们的 C++ SDK、第三方库、JVM 自身的本地部分、甚至驱动）触发了上述信号，就会 core。Java 侧经常见的情况是：Java→JNI→C++ 里发生越界/空指针/已释放内存访问，JVM 随之收到信号并把整个 Java 进程 core 出来（同时产生 hs_err_pid*.log）。
保存了什么：当时的所有线程的寄存器/调用栈、映射的可执行文件与共享库、部分内存段、少量元数据（ELF notes），足够让你事后用调试器复盘。

2) 我们现在是怎么“存储 core”的？配在哪儿看？

core 的“保存方式”由两层共同决定：系统级写到哪里 + 进程是否允许写。

A) 系统级（对整机上所有进程生效）

核心路径与方式：
```
bash
cat /proc/sys/kernel/core_pattern
```
- 若是普通路径模板（如 /var/core/core.%e.%p.%t），说明直接把 core 文件写到这个目录。
- 若以竖线 | 开头（如 |/usr/lib/systemd/systemd-coredump），说明核心被管道给收集器（常见是 systemd-coredump），实际存放在它管理的位置（通常 /var/lib/systemd/coredump/），配在：
```
bash
# systemd-coredump 行为/保留策略
grep -v '^\s*#' /etc/systemd/coredump.conf 2>/dev/null
# 或
systemctl cat systemd-coredump
```
是否允许产生 core（大小上限）：进程的 RLIMIT_CORE。
- 登录同一 shell 验证：
```
bash
ulimit -a | grep 'core file size'
```
- 正在运行的进程（含服务）：
```
bash
cat /proc/<pid>/limits | grep CORE
```

B) 服务/用户级（覆盖“是否允许写”和保留路径）

systemd 管理的服务（推荐你们线上都检查）：

bash
systemctl cat <your-service> | grep -i -E 'LimitCORE|ExecStart'
# 若无，考虑加上：
# LimitCORE=infinity

PAM/登录会话：/etc/security/limits.conf 或 /etc/security/limits.d/*.conf（对交互式 shell 有效）。
容器（Docker/K8s）：
- 容器启动是否带 --ulimit core=-1；
- namespace/capabilities 是否允许；
- 宿主机的 core_pattern 通常仍生效（但 core 文件最终落在宿主收集器处）。

小结：core_pattern 是系统全局的；是否真的会落盘还要看每个进程/服务的 ulimit（LimitCORE）。两者都满足才会有 core。

3) 从“一个 core 文件”如何定位到“哪个进程/哪台容器/看哪儿的日志”

这是你现在巡检最需要的“作战流程”。我给你一份最短路径决策树。

如果机器上启用了 systemd-coredump（core_pattern 以 `|...coredump` 开头）

找清单

bash
coredumpctl list               # 全部
coredumpctl list <comm>        # 按可执行名过滤（如 java、yhdfs）
coredumpctl info <PID或行号>   # 详细元数据（时间、Cmdline、CGroup、Unit、容器信息等）

核心信息你要抄走（定位日志很关键）

Exe（可执行路径）
Cmdline（包含程序参数；YARN 容器很有可能带 application/container 线索）
CGroup / Unit（能直接告诉你是哪个 systemd 单元或容器）
Timestamp（对齐你们业务日志时间线）

进 gdb 或 jhsdb

bash
coredumpctl gdb <id>       # 自动匹配可执行与库
# Java 进程的话，再：
coredumpctl dump <id> -o /tmp/core.java
jhsdb jstack --core /tmp/core.java --exe /usr/lib/jvm/.../bin/java

回溯到日志

systemd 服务：
journalctl -u <UnitName> --since 'YYYY-MM-DD HH:MM' --until '...'
或 journalctl _PID=<崩溃时PID>。
YARN（你说“容器里报错”这一类）：
- 应用聚合日志（RM/NM 配置 yarn.log-aggregation-enable=true 时）：
```
bash
yarn logs -applicationId <application_...>      # 拉整个应用
yarn logs -applicationId <...> -containerId <container_...>  # 精确到容器
```
- 本地 NodeManager 日志目录（常见）：
  - yarn.nodemanager.log-dirs（本地容器日志根目录）
  - 远端聚合目录 yarn.nodemanager.remote-app-log-dir
- 这些配置在 yarn-site.xml，你可以搜：
```
bash
grep -R "yarn.nodemanager.log-dirs\|remote-app-log-dir\|log-aggregation-enable" /etc/hadoop/conf/* 2>/dev/null
```
- 怎么从 core 找到 application/containerId？
  - 看 coredumpctl info 里的 Cmdline 与 CGroup（经常带有 container/app 线索）。
  - 你的业务日志/进程参数里通常会打印 applicationId/containerId（你们可以推动在 SDK 或启动脚本里把这些 ID 放进进程名或参数里，能极大降低定位成本）。
  - 实在没有，用时间戳交叉对齐 NodeManager 的 yarn-yarn-nodemanager-*.log 与 ResourceManager 的 yarn-yarn-resourcemanager-*.log，按崩溃时间附近搜该节点上哪个 container 刚刚失败/退出。

如果是“传统 core 文件”（直接落成文件）

看看它是哪来的：

bash
file core.*
readelf -n core.xxx | less          # NT_PRPSINFO/NT_FILE/Build-ID/信号等

直接进 gdb：

bash
gdb /path/to/exe /path/to/core
(gdb) set pagination off
(gdb) info sharedlibrary
(gdb) thread apply all bt
(gdb) info registers

“是谁”的线索放在：

gdb 的 可执行路径（第 1 行就能看到）；
readelf -n 里的 PRPSINFO（进程名）、时间、信号；
NT_FILE 映射列表里经常能看到工作目录/库路径（能反推到哪个组件）；
若是 Java，还要去崩溃时工作目录找 hs_err_pid*.log（或你们通过 -XX:ErrorFile= 指定的路径）。

小贴士：在 systemd-coredump 场景，优先用 coredumpctl info，它把“日志/单元/容器线索”都帮你聚合好了；传统 core 就靠 readelf -n + gdb + 现场目录结构来反推。

4) 传统 core vs systemd-coredump（对比速览）

维度	传统 core 文件	systemd-coredump
写入方式	直接写到 `core_pattern` 指定路径	`core_pattern` 管道给收集器
存放位置	你指定的目录（可能很散）	统一在 `/var/lib/systemd/coredump/`，文件名含元数据
附带元数据	仅 core 本体	journald 里保存了 Cmdline/CGroup/Unit/主机/时间/信号等
压缩/清理	你自己做	`coredump.conf` 可设压缩/保留空间上限
取用方式	`gdb exe core`	`coredumpctl list/info/gdb/dump`
适合场景	最小依赖、极简系统	规模化运维、便捷检索与保留策略

5) “为什么进程会自己崩溃？”（几类典型）

访问非法内存：空指针/越界/悬空指针 → SIGSEGV
显式终止：assert() 失败、abort()、glibc 检测到堆损坏（malloc(): memory corruption）→ SIGABRT
未捕获异常：C++ 异常穿透到 main 或 noexcept 违约 → std::terminate() → 通常 SIGABRT
非法指令/对齐：坏的函数指针跳转、SSE/AVX 指令不受支持 → SIGILL；未对齐访问/坏映射 → SIGBUS
算术错误：整型除 0、某些浮点异常 → SIGFPE

这些都可能在 JNI 调用栈里发生，从而把 Java 进程一起打成 core。

6) “寄存器/映射/ELF notes”该怎么读？（做最必要的）

x86_64 小抄

RIP：当前指令地址（崩溃点）
RSP：当前栈顶；RBP：栈帧基址（若未省略）
RDI,RSI,RDX,RCX,R8,R9：前 6 个整型/指针参数
RAX：返回值/临时；EFLAGS：标志位（ZF/CF …）
在 gdb 里：

gdb
(gdb) info registers
(gdb) disassemble /m $pc-32, $pc+64    # 看崩溃指令周围源码/汇编
(gdb) x/16gx $rsp                      # 看栈上的指针值
(gdb) bt full                          # 全栈 + 局部变量（有符号更清晰）

ELF notes（readelf -n core）

NT_PRSTATUS/PRPSINFO：线程/进程基本信息、信号
NT_AUXV：运行时辅助向量
NT_FILE：内存映射到文件的列表（含路径）
映射信息：info sharedlibrary 看具体加载了哪些 .so，版本是否对得上。

7) “native 崩溃是怎么崩？”（JNI 相关高频坑）

传错指针/越界：把 Java 数组指针拿出来用久了、越界读写 native buffer。
线程未附着 JVM：在 C++ 新建的线程里用 JNIEnv*（没 AttachCurrentThread）→ 未定义行为。
对象生命周期：把局部 jobject 缓存到全局用、或者忘记 NewGlobalRef/DeleteGlobalRef。
混 ABI/库版本：libprotobuf/libssl/zlib 等不同版本冲突，符号解析错位。
内存所有权不清：Java 传给 C++ 的内存释放职责没说清，出现 double free/use-after-free。

8) “C++ 的 SDK 会不会很难、是不是到处都是指针？”

不一定。现代 C++ 写法可以把风险显著降下来：

RAII / 智能指针：std::unique_ptr（唯一所有权）、std::shared_ptr（共享）、配合自定义 deleter；避免裸 new/delete。
少暴露裸指针：接口用 span/string_view/容器引用描述“借用”，谁分配谁释放。
错误返回：用 absl::StatusOr<T> / std::expected<T,E>（C++23）而不是返回魔数。
线程安全：明确哪一层创建线程、在哪一层做 AttachCurrentThread，JNI 入口/退出要“成对”。
工具链：ASan/UBSan/TSan 能提前把大量“会导致 core 的 bug”在测试阶段就抓出来。

9) 哪些“非核心问题”先记录、不阻塞主流程？

优先把**能复盘到“谁在何时何地崩”**这条链路打通；下面这些先记账，等主流程稳定再看：

提示“缺符号/符号不匹配”的 core（能定位到库但没行号）：先记录 build-id，交给打包/符号仓同学补齐。
与你们组件无关（Exe/Cmdline 看起来是别的进程）的 core：拉个 issue 分派给对应团队。
历史很久/版本已下线的 core：汇总后按版本批处理。
只见 SIGKILL（OOM killer 导致）且没有 core 的：转入“内存/资源”类巡检而不是崩溃定位。

10) 你可以直接抄用的命令串（SOP 迷你版）

bash
# A. 判断全局策略
cat /proc/sys/kernel/core_pattern
ulimit -a | grep core

# B. systemd-coredump 路径（若启用）
coredumpctl list
coredumpctl info <id> | sed -n '1,120p'
# 抄 Exe/Cmdline/CGroup/Unit/Timestamp/Signal
coredumpctl gdb <id> -A   # 进 gdb
# Java 额外
coredumpctl dump <id> -o /tmp/core.java
jhsdb jstack --core /tmp/core.java --exe /usr/bin/java | tee /tmp/jstack.txt

# C. 传统 core
file core.*
readelf -n core.* | sed -n '1,200p'
gdb /path/to/exe /path/to/core -ex 'set pagination off' \
    -ex 'info sharedlibrary' -ex 'thread apply all bt full' -ex 'quit' | tee /tmp/bt.txt

# D. YARN 日志（已知 app/containerId）
yarn logs -applicationId application_... > app.log
yarn logs -applicationId application_... -containerId container_... > container.log
# 若未知，按崩溃时间去 NodeManager/ResourceManager 日志里 grep 附近的失败记录

如果你愿意，把你们一台线上节点的 core_pattern、某个 core 的 coredumpctl info 输出（去除敏感字段）贴给我，我就按这条 SOP 帮你把**“core → 进程/容器 → 日志路径”**这条链路走一遍，并且一起把你们的巡检清单（哪些立即做、哪些先记录）固化下来。

Answer 3

太好了，这段 readelf 输出已经能给出很多线索。你贴的几条 gdb 命令也都是分析 core 的“基础四件套”。下面我把每条命令的作用 → 会产出什么信息 → 怎么用这些信息定位进程/容器/日志给你逐条说清楚，并顺手解析一下你这份 readelf 片段。

1) `readelf -n core.xxx`（读 core 里的 ELF notes）

作用：把 core 文件里“NOTE 区”的元数据（不是代码数据）打印出来。
会产出（你贴出来的几项）：

NT_PRSTATUS：线程状态快照（寄存器、当前信号、栈指针等）。用于确认崩溃线程的寄存器。
NT_PRPSINFO：进程信息（进程名、PID、PPID、UID/GID、短的命令行摘要）。用于确认是谁的进程。
NT_SIGINFO：触发 core 的信号详情（si_signo/si_code/si_addr 等，si_addr 常是出错访问的地址）。
NT_AUXV：进程的 auxiliary vector（平台/加载器参数，平时很少直接用）。
NT_FILE：内存映射的文件列表（页大小、每个映射的 Start/End、页偏移、文件路径）。这是定位“到底加载了哪些 .so/.jar/可执行文件”的关键。

你这份 NT_FILE 的几个关键信息我帮你圈一下（很有用）：

Page size: 4096：页大小，后面“Page Offset”列是以页为单位的偏移；真实文件偏移 = Page Offset * 4096。
两条指向 jdk1.8.0_60/bin/java 的映射（0x400000... 和 0x600000...）说明崩溃的就是 Java 进程（JDK 1.8.0_60）。
看到 .../jre/lib/ext/cldrdata.jar、/usr/lib64/liblzo2.so.2.0.0、/usr/lib64/libstdc++.so.6.0.25 等，说明进程加载了这些库/资源。
最有价值的线索：
```
/export/Data/tmp/hadoop-tmp/nm-local-dir/usercache/root/appcache/application_1754969617538_4473/container_e41_1754969617538_4473_01_000127/tmp/unpacked-...-libgplcompression.so (deleted)
```
- 路径里直接带 applicationId 和 containerId：
  - application_1754969617538_4473
  - container_e41_1754969617538_4473_01_000127
- 后缀 (deleted) 的意义：该 .so 在进程运行期间被 unlink（删除）了，但内存里依然映射着它（因此 core 还能看到路径）。这在 YARN 容器把 native 依赖临时解包到 tmp/unpacked-* 然后退出时很常见。
- 有了这两个 ID，你就能精确拉 YARN 聚合日志（见第 4 节）。

小结：readelf -n 主要让你在不进 gdb 前就拿到“是谁（Java）、为什么（信号）、加载了什么（NT_FILE）、在哪个 YARN 容器（路径里包含 application/containerId）”。

2) `gdb` 里的四条命令

先假设你是这样进 gdb 的：

bash
gdb /export/App/jdk1.8.0_60/bin/java /path/to/core

a) `set pagination off`

作用：关掉 gdb 的分页提示（那行 “--Type <return> to continue--”）。
产出：不是数据，而是让后续打印一口气吐完，方便重定向保存：

bash
gdb ... -ex 'set pagination off' -ex 'thread apply all bt full' ...

b) `info sharedlibrary`

作用：列出当前进程（core 中的状态）加载的所有共享库、它们的加载基址（0x...）、以及 gdb 是否成功为它们加载了符号（Yes/No）。
产出：一张“库 → 加载地址 → 符号是否可用”的清单。
怎么用：

确认版本是否对得上（例如 libstdc++.so.6.0.25）。
如果某库 Symbols: no，说明没有调试符号；解决方案是：
- 在相同版本机器上安装 -debuginfo 包 / .debug 文件；或
- 用 set debug-file-directory / set solib-search-path 指向你们的符号仓。
崩溃回溯里出现的地址是相对这个加载基址可还原源码行的（配合 addr2line 或 list）。

c) `thread apply all bt`

作用：对所有线程执行 bt（backtrace）。
产出：每个线程的调用栈（函数名 + 偏移 + 地址）。
提示：

推荐用更信息量大的：
```
gdb
thread apply all bt full
```
full 会打印局部变量/参数值（有符号时很有用），快速看出是空指针、越界还是已释放内存。
结合 info threads 找到触发信号的线程（通常在回溯顶部能看到 SIGSEGV 等字样，或看 Program terminated with signal ...）。

d) `info registers`

作用：打印当前选中线程的寄存器（x86_64 的 RIP/RSP/RBP/RDI/...）。
产出：崩溃点地址（RIP）、栈顶（RSP）、函数参数寄存器（RDI/RSI/RDX/...）等。
怎么用：

RIP 就是崩溃指令地址，常配合：
```
gdb
disassemble /m $pc-32, $pc+64
```
看出错指令附近的源码与汇编。
参数寄存器结合 bt full 的形参，能判断是不是传了野指针/空指针。
想切换到崩溃线程后再看寄存器：
```
gdb
thread <崩溃线程号>
info registers
```

3) 有了这些输出，下一步怎么定位日志与容器（结合你这份 core）

你这份 NT_FILE 已经暴露了 applicationId 与 containerId，因此可以直接拉 YARN 聚合日志：

bash
# 拉整个应用
yarn logs -applicationId application_1754969617538_4473 > app.log

# 精确到容器
yarn logs -applicationId application_1754969617538_4473 \
          -containerId   container_e41_1754969617538_4473_01_000127 > container_127.log

另外再查 JVM 自带的崩溃文件（如果有配置更好）：

bash
# 如果 JVM 参数里设了 -XX:ErrorFile=...
# 不知道的话，先在预计工作目录或节点上全局搜
find /export -maxdepth 5 -name 'hs_err_pid*.log' -mmin -120

hs_err_pid*.log 能直接告诉你崩溃线程/信号/Java 栈以及 JNI 桥接点，和 gdb 的 native 栈相互印证。

4) 看到 `(deleted)` 要不要慌？

不慌。它只是说明该 .so 在文件系统里被删除（或临时文件已清理），但仍在进程地址空间里。
对定位的影响：

优点：路径里露出 application/containerId，给了你直达日志的钥匙。
注意：符号解析可能找不到这份已删除的 .so。解决方法：
- 在构建/发版阶段把对应版本的 .so 和 .debug 放进符号仓（按 Build-ID 存放最佳）；
- gdb 里通过 set solib-search-path 指向这份仓库，或 add-symbol-file 加载符号。

5) 最后给你一个“最短命令清单”（直接复制用）

bash
# 1) 先看 core notes，拿到容器/应用线索
readelf -n /path/to/core | less

# 2) 用 gdb 出全量回溯（保存到文件）
gdb /export/App/jdk1.8.0_60/bin/java /path/to/core \
  -ex 'set pagination off' \
  -ex 'info sharedlibrary' \
  -ex 'thread apply all bt full' \
  -ex 'quit' | tee /tmp/bt.txt

# 3) 通过 readelf 里看到的 applicationId/containerId 拉日志
yarn logs -applicationId application_1754969617538_4473 > app.log
yarn logs -applicationId application_1754969617538_4473 \
          -containerId container_e41_1754969617538_4473_01_000127 > container_127.log

# 4)（可选）找 hs_err（如果 JVM 崩溃会写）
find /export -name 'hs_err_pid*.log' -mmin -120

如果你愿意，把这份 core 的触发信号（NT_SIGINFO）以及你跑完 thread apply all bt full 的前 30 行贴过来（去敏），我可以帮你判断是“空指针/越界/已释放内存/断言失败/库冲突”里的哪一类，并给出下一步要抓的符号或日志点。

Answer 4

超级好的样本！我按你给的输出，把“4 条命令的作用/产出/怎么读”说清楚，再回答你几个关键概念（加载基址、bt vs thread apply all bt full、如何判定空/野指针），最后结合你这份回溯给出“下一步怎么查”。

一、4 条命令到底做什么、产出什么

1) `readelf -n core.xxx`

做什么：读取 core 里的 ELF notes（内核写进 core 的“元数据”）。
产出（你看到的）：

NT_PRSTATUS：某个线程的寄存器、当时收到的信号等。
NT_PRPSINFO：进程名、PID、UID/GID、命令行摘要。
NT_SIGINFO：触发 core 的具体信号（si_signo/si_code/si_addr）。si_addr 常是出错地址。
NT_AUXV：辅助向量（平台/加载器参数）。
NT_FILE：所有内存映射文件（Start/End/页偏移/路径）。
你这份里最有用的是：
- 可执行程序是 /export/App/jdk1.8.0_60/bin/java（说明崩的是 Java 进程）。
- 路径里直接出现 application_... 和 container_...（YARN 应用与容器 ID），而且若干 .so 标注 (deleted)，典型 YARN 临时解包后清理了文件，但仍在内存映射中。

用途：即便不进 gdb，也能知道谁崩的、什么信号、加载了哪些库、是哪一个 YARN 容器。

2) `set pagination off`

做什么：关闭 gdb 的分页提示。
产出：不是数据，而是让接下来的输出一口气打印，便于 | tee 保存。

3) `info sharedlibrary`

做什么：列出当时加载的所有共享库，每个库的加载基址范围（From/To）以及是否读到了符号。
你这份输出怎么读：

From/To：这是加载基址区间（下面有解释“什么是加载基址”）。ASLR 环境里每次地址会变。
Syms Read 列：
- Yes (*)：加载到了符号表，但没有调试符号（即只有函数名，缺行号/局部变量）；
- Yes（无星号）：既有符号也可能含调试信息（是否有行号要看具体包是否带 debuginfo）；
- No：没有符号（gdb 只能看到裸地址，几乎没有可读性）。
两个 No 很关键：
- /.../tmp/jffi....so（JNR/JFFI 生成的 JNI 动态库）
- /.../unpacked-...-libgplcompression.so（已删除的临时 .so）这两处如果参与崩溃，必须补齐对应版本的符号或把 .so 文件再放回来（或从符号仓通过 Build-ID 映射）。

用途：确认库版本、符号是否齐全、以及崩溃栈里地址如何做“基址+偏移”的还原。

4) `info threads` / `bt` / `thread apply all bt full`

info threads：列出所有线程（每个都有 gdb 的 Id、LWP（内核线程号）、当前栈顶函数）。
- 你看到很多线程停在 pthread_cond_wait / epoll_wait / nanosleep，这是很正常：核心转储时，只有“收到致命信号/主动 abort 的那个线程”是“出事线程”，其他线程只是被一并快照，方便你排查死锁/卡住/线程间关系。
bt：当前选中线程的回溯（栈）。你粘贴的 bt 是线程 1（带星号的那行）。
thread apply all bt full：对所有线程做 bt full。
- full 的意义是：尽量打印形参/局部变量的值，配合调试符号能看到指针/长度等，更易判断空指针/越界。
- 和 bt 的关系：bt 只看一个线程；thread apply all bt full 一次性看所有线程，信息量最大，通常用于把现场完整保存到文件。

用途：

快速锁定出事的线程（回溯里往往能看到 raise/abort/signalHandler、或“Program terminated with signal…”）；

观察其它线程是否有死锁/卡 wait，是否与崩溃线程有资源关系（比如持有某个互斥/读写锁）。

二、关键概念与你的具体问题

1) “加载基址”是什么？

内存里每个共享库（*.so）会被映射到一个基址（base address），后续函数在该库内的地址 = 基址 + 偏移。

由于 ASLR（地址空间随机化），基址每次都可能不同。
gdb 的 info sharedlibrary 里 From 就可以看作“当前这次运行时的加载基址”（精确来说是该库某段的起始映射地址）。
当你只有“崩溃地址”但库没有行号时，可以用：
1. 计算偏移：offset = 崩溃地址 - 加载基址（From）
2. addr2line -e /path/to/lib.so 0x<offset> 还原到源码行（前提是你手里这份 lib.so 带符号或有 .debug 文件）。

2) `bt` vs `thread apply all bt full` 的关系？

bt = 当前线程回溯。
thread apply all bt full = 所有线程的回溯 + 形参/局部变量（如果有符号）。
为什么 core 里会有这么多线程？
因为 core 是整个进程的快照，触发崩溃的是其中一个线程（收到信号或调用 abort()），但为了帮助你排查线程间问题，内核把 所有线程 的上下文都写进 core。

3) 如何判断空指针还是野指针？

常用的三把锤子：

A. 看 NT_SIGINFO 的 si_addr（readelf -n core 或 gdb 里 info signals/p $_siginfo）

si_addr = 0x0 或非常小的地址：极大概率空指针解引用（SIGSEGV）。
一个看起来“随机的大地址”，而且不在任何映射区间里：像野指针（悬空、越界算出来的垃圾地址）。

B. 在 gdb 里看崩溃线程的寄存器/参数

gdb
# 选中崩溃线程
(gdb) thread <id>
(gdb) info registers             # 看 RDI/RSI/RDX...（x86_64 调用前6个参数寄存器）
(gdb) bt full                    # 看形参打印出来的指针值/长度
(gdb) x/gx 0xDEADBEEF...         # 尝试读该地址（读不出来往往是未映射）

参数寄存器里出现 0x0 被当作对象/指针使用 → 空指针。
参数是个“不像样”的地址，x/gx 报错或落在 unmapped 区域 → 野指针。

C. 查内核日志 / dmesg

dmesg 里常有一行：segfault at <addr> ip <pc> sp <sp> error ... in libX.so[base+off]
<addr> 与 ip 提示了“访问的内存地址”和“执行位置”，配合 info sharedlibrary 的基址能快速换算到库内偏移。

注意：你这份 bt 的顶部是 raise -> abort -> libjvm.so，看起来是 JVM 主动触发了致命错误流程（可能是捕获到某个信号后调用 report_and_die() 再 abort()）。这种情况下，原始的故障地址不要只看 #0~#3，要去找：

#6 <signal handler called> 之前的原始帧（如果保留在 core 里能看到），或

JVM 的 hs_err_pid*.log 里的 Problematic frame 与 siginfo（最直接），或

readelf -n 的 NT_SIGINFO.si_addr。

三、把你这份输出连起来看（重点提示你下一步怎么查）

1) 从 `info sharedlibrary`

崩溃进程是 JDK 1.8.0_60 的 java。
关键本地库：libjvm.so、libstdc++.so.6、/export/Data/tmp/hadoop-tmp/libjdufs_sdk.so（你们的 UFS SDK？）、libhadoop.so、以及 两处 Syms Read: No 的临时 JNI so（jffi*.so、libgplcompression.so (deleted)）。
结论：native 侧有大量参与者，必须保证“定位真正出错帧的那个 .so 有符号”。

2) 从 `info threads`

绝大多数线程在 pthread_cond_wait/epoll_wait，说明系统正常“多数线程在等”。
星号线程（#1）在 raise -> abort 上，这是“正在执行致命错误流程的线程”。

3) 从 `bt`

#0 raise -> #1 abort -> #2 os::abort -> #3 VMError::report_and_die -> #4/#5 JVM_handle_linux_signal/signalHandler：
这是 HotSpot 捕获信号、打印 fatal error、最终走 abort 的标准路径。
#6 <signal handler called>：表明之前发生过一个信号（通常是 SIGSEGV/SIGBUS/SIGILL/SIGFPE 之一），被 HotSpot 的 handler 接住。
#7 之后进入你们 native 代码（spdlog）**的调用链**（TcpTransportExtend::doRecv` 等）：
这说明出事的那个线程是 native 线程（std::thread），在做网络/日志相关工作**。
- 这里有两种常见可能：
  1. 真正的非法内存访问发生在 doRecv（或它调用链更深处），被 JVM handler 捕获；
  2. 并不是非法访问，而是 JVM/GLIBC 主动 abort（如堆破坏 malloc(): memory corruption、致命断言），导致这条 abort 栈（也就会看见 raise/abort 顶在前面）。

下一步最关键的判断：到底是“信号类崩溃（比如 SIGSEGV）”还是“主动 abort（如断言失败/堆损坏）”。

去 core 里看 NT_SIGINFO 的 si_signo/si_addr；
找 hs_err_pid*.log（如果开启了 -XX:ErrorFile 更容易找），看 Problematic frame 和 siginfo。

四、你可以直接照做的检查清单（针对这份 core）

看信号细节（最重要一步）

bash
# 核心转储里的信号信息
readelf -n /path/to/core | sed -n '1,160p'   # 找 NT_SIGINFO 段，抄 si_signo/si_addr

如果 si_signo = SIGSEGV 且 si_addr = 0x0 → 空指针很可能；
如果 si_addr 是一个奇怪的大地址 → 倾向野指针/越界；
如果信号是 SIGABRT → 倾向主动 abort（断言、堆损坏等），要找stderr / hs_err 里的报错关键字。

把“出事线程”细看一遍

gdb
(gdb) thread 1                    # 你的星号在线程 1
(gdb) bt full
(gdb) f 12                        # 跳到 #12 doRecv
(gdb) list                        # 看源码（需有调试符号）
(gdb) info args; info locals      # 看形参/局部（指针/长度）
(gdb) p this
(gdb) x/gx this                   # 这类指针是否合理（非 0、落在映射内）

若没有行号/局部变量，先补符号；或者用加载基址换算偏移，addr2line 定位源码。

找 hs_err_pid*.log

bash
find /export -name 'hs_err_pid*.log' -mmin -180
# 或者查看 JVM 启动参数是否有 -XX:ErrorFile 指定

里面会明确写：# A fatal error has been detected by the Java Runtime Environment:
SIGSEGV/SIGABRT、Problematic frame: ... in <lib>.so+0x<offset>，这能直接告诉你哪个库的哪个偏移触发了问题。

抓 YARN 日志
你之前 NT_FILE 里已经给了 application_... 与 container_...，直接拉：

bash
yarn logs -applicationId application_1754969617538_4473 \
          -containerId   container_e41_1754969617538_4473_01_000127 \
          > container_127.log

如果是主动 abort（比如 glibc 报堆损坏），常能在容器日志里看到原始报错语句。

五、顺手回答：为什么会有多个线程“对 core 产生影响”？

核心转储包含整个进程的所有线程。真正触发崩溃的是其中一个（收到信号/调用 abort()），但其它线程的状态对判断死锁、资源竞争、是否有后台刷日志/网络 I/O 卡住很重要。所以我们总是用 thread apply all bt full 把“群像”拿到手，再重点分析“致命线程”。

六、针对你这份回溯的两个提醒

Syms Read: No 的两个 JNI so（jffi*.so、libgplcompression.so）如果参与了调用链，必须补符号（或保留一份未删除的 so），否则就算看到“库+偏移”，也无法快速还原到源码行。
spdlog 出现在崩溃线程的链路上（flush_ / sink_it_ / log_it_），不一定是 spdlog 的错，更可能是你们在 doRecv 里写日志时用了无效内存（空/野指针），导致格式化参数访问出错。bt full 里看形参（尤其是 string/buffer 指针与长度）往往一眼能看出来。

需要的话，你把 readelf -n 里 NT_SIGINFO 的三项（si_signo/si_code/si_addr）贴一下，再加上 bt full 中 #12 doRecv 那几帧的“形参和局部变量”部分（去掉敏感内容）。我就能告诉你是空指针还是野指针/越界的概率更大，并给出具体的“该看哪段代码/该打哪些保护（边界检查/nullptr 检查）”。

Answer 5

很好的问题！我按你问的点逐个讲清楚，并给出落地做法与常用命令。

1) “符号表”“调试符号”“补符号”分别是什么？

可执行/共享库（ELF）里可能有三类和符号相关的东西：

.dynsym（动态符号表）
- 供动态链接用，只有对外可见的符号（导出函数、全局变量等），信息很“瘦”。
- 有了它，gdb 至少能把很多帧还原成函数名，但没有源码行号、没有局部变量。
.symtab（完整符号表）
- 含更多本地符号，但通常随发布会被剥离（strip）以减小体积、隐藏实现。
DWARF 调试信息（.debug_* 段）
- 真正让 gdb 显示源码文件/行号、形参与局部变量、内联展开、类型信息的部分。
- 这部分一般放在单独的 debuginfo 文件里（例如 libxyz.so.debug），或通过 build-id 仓库统一管理。

gdb 里 “Syms Read: Yes (*)” 的含义

Yes (*)：读到了符号，但缺调试信息（只有函数名、没有行号/局部变量）。
Yes（无星号）：通常表示能拿到足够的调试信息（具体是否有行号要看构建方式）。
No：连函数名都没有，只能看裸地址。

“补符号” 就是：
把与你崩溃二进制完全一致的调试符号文件（或未 strip 的二进制）找回来，让 gdb 能显示行号/局部变量。常见做法：

发行版 debuginfo 包：
- RHEL/CentOS：debuginfo-install glibc libstdc++ ...
- Debian/Ubuntu：apt-get install libc6-dbg ...
你们自家构建产物：打包时保留 .debug 文件，按 Build-ID 存在“符号仓”（/usr/lib/debug/.build-id/xx/yyyyyy.debug），分析机器上 debug-file-directory 指到这个仓库即可。
临时：把同版本未 strip 的 .so 放到一台“分析机”，gdb 用 set solib-search-path 指过去。

2) “共享库之间是完全连着的吗？和段页式管理有关吗？”

不是“拼成一个大文件”的那种连着。运行时的情况是：

每个 .so 都被内核按页（通常 4K）映射到同一进程的虚拟地址空间不同区域（这才会有你看到的 From/To 加载区间）。
调用跨库函数时，通过动态链接器（PLT/GOT、重定位表）把“符号名”解析到“某库的实际地址”，从而跳转。
ASLR 让每次运行同一库的加载基址不同，所以我们常常用“加载基址 + 偏移”来定位库内具体指令。
段页式内存管理是操作系统的底层实现（虚拟内存、按页映射、权限控制），它让“把很多库映射到一个进程的地址空间里”成为可能，但排障时你关注的是映射结果（地址区间/基址），不需要深究 MMU 细节。

一句话：它们在同一进程里“彼此可调用”，但物理上是各自独立的文件，被映射到不同虚拟区间。

3) “去 core 里看 NT_SIGINFO 的 si_signo / si_addr 是啥意思？”

在 readelf -n core 的 NT_SIGINFO 段里：

si_signo：触发核心转储的信号编号（如 SIGSEGV、SIGABRT、SIGBUS、SIGFPE、SIGILL）。
si_code：信号来源和子类型（例如 SEGV_MAPERR 未映射地址、SEGV_ACCERR 权限错误；FPE_INTDIV 整数除零等）。
si_addr：对内存访问类信号（SEGV/BUS），这里给出出错访问的地址：
- 0x0 或极小 → 空指针解引用高度可疑；
- 一个“很怪的、既不对齐又不在任何映射里的大地址” → 野指针/越界可疑；
- 对 SIGABRT 通常无意义（是主动 abort()）。

怎么看（两种方式）

bash
# 直接从 core 读取
readelf -n /path/to/core | sed -n '1,160p'   # 找 NT_SIGINFO 小节

# 在 gdb 里（更快）
(gdb) p $_siginfo     # 打印当前线程的 siginfo_t（若 core 由信号触发）

4) “跳到 #12 doRecv 的目的是什么？”

你的 bt 里第 12 帧是：

text
#12 kunlun::netlib::TcpTransportExtend::doRecv(...)
    at .../tcp_transport_extend.cpp:421

目的：定位到发生问题的业务代码“上下文”，检查函数参数/局部变量是否异常（空/越界/悬空），从而判断根因。

怎么做：

gdb
(gdb) frame 12           # 或 f 12，选中那一帧
(gdb) list               # 看 421 行上下代码（需要调试符号）
(gdb) info args          # 打印形参（指针、长度、引用等）
(gdb) info locals        # 打印局部变量
(gdb) p this             # 看 this 是否合理（非 0）
(gdb) x/gx 0x...         # 对可疑指针地址做内存探针（看是否映射/可读）

为什么不只看最顶上几帧（raise/abort/libjvm）？
那是JVM 的致命错误处理路径；真正的错误很可能在再下一层（例如你的 doRecv、或 spdlog 里访问了坏内存）。所以我们要“下潜到你的代码帧”。

5) “是否需要定位到具体哪个 .so 报错？然后结合日志分析上下文？”

是的，这是标准流程。 一个靠谱的闭环通常是：

先确定信号与关键帧
- 看 NT_SIGINFO.si_signo/si_addr，判断“信号类型/出错地址”；
- 在 gdb 栈里找到业务相关的那一帧（比如你的 doRecv 或紧邻它的库调用）。
定位到具体库 + 偏移 + 源码行
- 如果 bt 已经给出“文件:行号”，很棒；
- 如果只看到“库 + 地址”，就用加载基址换算偏移，再 addr2line：
```
bash
# 例：fault_ip = 0x7fe296c20ab7, 基址 From = 0x7fe296...（见 info sharedlibrary）
# offset = fault_ip - base
addr2line -e /path/to/libxxx.so 0x<offset>
```
- 缺行号/缺局部变量 → “补符号”。
拉对应容器/进程的日志，拼时间线
- 你已经从 NT_FILE 拿到 applicationId/containerId，用 yarn logs -applicationId ... -containerId ...；
- 再找 JVM 的 hs_err_pid*.log（若有）：里面会写 Problematic frame: ... in libYYY.so+0xOFFSET，对齐 core 结果。
- 看崩溃前是否有**“malloc(): memory corruption”、“double free”、“stack smashing”** 等致命语句；或是业务 WARN/ERROR。
判定空指针/野指针/堆损坏
- 空指针：si_addr=0x0，info args/locals 里某对象/指针为 0，却被解引用。
- 野指针/越界：si_addr 在未映射区，或明显越界（例如长度 16 的 buffer 被写到 200 字节）；
- 堆损坏/主动 abort：si_signo=SIGABRT，日志或 hs_err 里有 glibc/ASan 的报错；回溯里常见 __libc_malloc/free 附近帧。
注意“当前出错帧未必是根因”
- 常见情况是更早的越界写把堆/对象破坏了，稍后在 spdlog 或别的库里读到这块坏内存才崩。
- 这时线上只能定位“报错点”；要在测试环境复现并用 ASan/UBSan/TSan/Valgrind 把“首次非法写”抓出来。

一些你可以直接用的命令／套路

看信号信息

bash
readelf -n core | sed -n '1,160p'       # 找 NT_SIGINFO
# 或 gdb 内
(gdb) p $_siginfo

基址换算偏移 + 行号

bash
# 先看基址
(gdb) info sharedlibrary | grep libjdufs_sdk.so
# 计算 offset = fault_ip - base，然后：
addr2line -fe /export/Data/tmp/hadoop-tmp/libjdufs_sdk.so 0x<offset>

补符号的两种路径
1. 系统库：debuginfo-install glibc libstdc++ zlib ... 或 apt-get install ...-dbg
2. 你们自家库：把同一构建的 .debug 放到 /usr/lib/debug/.build-id/xx/xxxx.debug，或用
```
gdb
(gdb) set debug-file-directory /path/to/debug-repo
(gdb) set solib-search-path     /path/to/so-repo
```

选中关键帧看变量

gdb
(gdb) f 12
(gdb) list
(gdb) info args
(gdb) info locals
(gdb) disassemble /m $pc-32, $pc+64

拉容器日志与 hs_err

bash
yarn logs -applicationId application_... -containerId container_... > container.log
find /export -name 'hs_err_pid*.log' -mmin 180

小结（把你的问题串成一句话的答案）

符号表让 gdb 知道函数名，调试符号让 gdb 知道行号与变量；“补符号”就是把与崩溃二进制匹配的调试信息补齐到分析环境。
共享库不是“拼接在一起”，而是各自映射到同一进程地址空间，通过动态链接机制互相调用；这依赖 OS 的虚拟内存/分页，但排障时你只需关心加载基址与映射区间。
NT_SIGINFO 的 si_signo/si_addr 告诉你是什么信号、访问了哪个地址，常用于判断空指针（0 地址）还是野指针/越界（怪地址）。
跳到 #12 doRecv 是为了在你的业务代码帧里看参数/局部变量，结合加载基址/偏移和容器/JVM 日志，最终判定“是哪一个 .so 的哪一行”出问题，以及它是空指针/野指针/堆损坏中的哪一类。

如果你愿意，把 p $_siginfo 的输出和 frame 12 的 info args/locals（去敏）贴一下，我就按上述套路帮你直接判空/野指针的大概率方向，并给出要补哪份符号、看哪段日志。

Answer 6

太棒了，这些都是把 core 用“内行人方式”吃透的关键点。我分 6 段来答：

你说“没看到 si_signo/si_addr”，到底去哪儿看；
“符号/调试符号/补符号”再捋一遍；
动态链接、.so、Java 如何调用 .so、为啥要 strip；
虚拟地址空间 & “加载基址”到底怎么回事；
为什么要跳到 #12 doRecv；
“早写晚崩”与 ASan/UBSan/TSan/Valgrind 怎么理解 & 落地。

1) 为啥你在 `readelf -n` 里没看到 si_signo/si_addr？应该去哪儿看

你贴的 readelf -n 输出只是 NOTE header 的目录（“这里有个 NT_SIGINFO 块”），GNU readelf 默认不展开 siginfo_t 的字段，所以不会直接显示 si_signo/si_addr。这没问题，工具就是这样。
正确的、最直接的看法是在 gdb 里读 core 的“信号现场”：

gdb
# 打开 core
gdb /export/App/jdk1.8.0_60/bin/java /path/to/core
(gdb) p $_siginfo          # 打印 siginfo_t（含 si_signo/si_code/si_addr 等）
# 也可以单看字段
(gdb) p $_siginfo.si_signo
(gdb) p $_siginfo.si_code
(gdb) p $_siginfo._sifields._sigfault.si_addr   # 有的架构字段名略有差异，用 p $_siginfo 先看结构

如果你暂时不进 gdb，也可从 内核日志看“faulting address”：
```
dmesg | grep -E 'segfault|trap|general protection|bus error'
```
常见格式：segfault at <addr> ip <pc> sp <sp> error ... in <lib>[base+off]，里面的 <addr> 就是“访问的地址”（空指针常见为 0）。

结论：readelf -n 只告诉你“有 NT_SIGINFO”；想看 si_signo/si_addr，进 gdb 用 p $_siginfo。

2) 符号表 / 调试符号 / “补符号”到底是啥

动态符号表 .dynsym：给动态链接器用，含“导出函数/变量”的符号名。有它，gdb 至少能显示函数名；但没有源码行/局部变量。
完整符号表 .symtab：更多本地符号，发布时常被 strip 掉。
调试信息（DWARF，.debug_* 段）：让 gdb 有源码文件/行号、内联、局部变量和类型。

info sharedlibrary 的 “Syms Read” 列：

Yes (*) = 读到符号但无调试信息（能见函数名，但无行号/局部变量）。
Yes（无星号）= 通常表示能拿到调试信息（视构建而定）。
No = 连函数名都没有，只是地址。

“补符号”就是：把与你崩溃时二进制完全一致的调试信息放回分析环境，让 gdb 能“指到行、看变量”。做法：

系统库：安装 debuginfo 包（RHEL/CentOS 用 debuginfo-install glibc libstdc++ ...；Debian/Ubuntu 用 *-dbg）。
你们自家库：构建时产出 .debug 或不 strip 的版本，按 Build-ID 存到符号仓（/usr/lib/debug/.build-id/xx/yyyyyy.debug）；分析时：
```
gdb
(gdb) set debug-file-directory /path/to/debug-repo
(gdb) set solib-search-path     /path/to/so-repo
```

3) 动态链接 / `.so` / Java 怎么调 `.so` / 为什么 strip

动态链接：你的可执行文件在运行时通过动态链接器（/lib64/ld-linux-*.so.2）把需要的共享库（.so）映射进进程，并把函数调用通过 PLT/GOT 解析到正确地址。这样可复用库、节省内存、便于更新。
.so 是什么：ELF 共享库（Shared Object）。被多个进程共享映射（代码段只读共享）。

Java 如何用 .so：通过 JNI/JNA/JNR。常见调用：

java
System.loadLibrary("hadoop");   // 走 java.library.path
System.load("/abs/path/libxxx.so"); // 绝对路径

然后 JVM 里 native 方法就能跳到 C/C++ 的实现。

为啥 strip：减小体积、降低符号泄露风险。strip 后线上库更小更快，但分析时需要单独的 .debug 文件来还原。

4) 虚拟地址空间 & “加载基址”怎么理解（跟“看偏移”强相关）

虚拟地址空间（VAS）：每个进程看到的是“自己的”连续地址空间；不同 .so 会被映射到不同的区间（你在 NT_FILE 里看到的 Start/End）。物理内存由内核和 MMU 管理；进程之间相互隔离。
加载基址（base address）：某个 .so 本次运行被映射到的起始地址（ASLR 每次可能不同）。
info sharedlibrary 的 From 就是“可以当作基址”的值。
为什么老在算“偏移”：因为地址随机化，库内的崩溃点= 基址 + 偏移。我们把 崩溃地址 - 基址 = 偏移，再用：
```
bash
addr2line -fe /path/to/libxxx.so 0x<偏移>
```
定位源码行（前提：该库有调试信息或 .debug 文件）。

5) 为什么要跳到 `#12 doRecv`（而不是停在 `raise/abort/libjvm.so`）

你贴的 bt 顶部是 raise → abort → libjvm.so 的 fatal path，这是JVM 在处理致命信号/错误时的通用“收尾栈”，信息价值有限。
真正有价值的是“事发前的业务栈”：在你的样本里就是 #12 doRecv 往下的几帧（spdlog::... → doRecv → NetEvent...）。
目的：
1. 看形参/局部变量（需要调试符号）：是否有 NULL/长度异常/悬垂引用；
2. 结合 $_siginfo 的 si_signo/si_addr，判断这是空指针/野指针/越界还是主动 abort；
3. 再回头看容器/JVM 日志里崩溃前的 WARN/ERROR，拼出现场。

操作小抄：

gdb
(gdb) f 12
(gdb) list
(gdb) info args
(gdb) info locals
(gdb) p this
(gdb) p $_siginfo
(gdb) disassemble /m $pc-32, $pc+64

6) “早写晚崩”的理解 & ASan/UBSan/TSan/Valgrind 怎么用

很多 native 崩溃是更早的“非法写”破坏了内存，过一会儿别的代码（比如 spdlog 格式化字符串）“碰到这块坏内存”才崩。线上 core 只能告诉你“撞墙点”，不一定能告诉你“第一次挖坑点”。

怎么抓“第一次挖坑点”（测试/预发环境）：

编译开 Sanitizer（推荐）
- AddressSanitizer（ASan）：抓越界、UAF、double free 等
- UndefinedBehaviorSanitizer（UBSan）：抓未定义行为
- ThreadSanitizer（TSan）：抓数据竞争
  典型编译参数（GCC/Clang）：
```
bash
# Debug 或预发构建
-g -O1 -fno-omit-frame-pointer \
-fsanitize=address,undefined    # ASan + UBSan
# 多线程问题排查专用
-fsanitize=thread               # TSan（与 ASan 不能同时开）
```
运行时会直接在第一次非法写发生的那一行报错并堆栈，价值极高。
Valgrind（Memcheck）
- 不需要重编译，慢但严谨。
- 运行：
```
bash
valgrind --tool=memcheck --leak-check=full --track-origins=yes ./your_binary ...
```
- 能报告无效读写/越界/泄漏以及“这个指针最初从哪儿来”。
复现策略
- 复刻与线上相同的输入/配置；
- 关闭过度优化（-O0/-O1），保留帧指针（-fno-omit-frame-pointer）；
- 把日志等级调高，在 suspect 路径加边界检查与断言，一旦发现异常 abort() 让现场尽早暴露。

实战心法：线上 core 定“撞墙点” → 日志/指标定位“触发条件” → 测试/预发开 Sanitizer 抓“第一次挖坑点”。

把你的问题串成“行动项”

打开 core 于 gdb，直接看信号：

gdb
gdb /export/App/jdk1.8.0_60/bin/java /path/to/core
(gdb) p $_siginfo                 # 看 si_signo/si_addr

找到业务帧并看变量：

gdb
(gdb) f 12
(gdb) info args
(gdb) info locals

不够细？补符号：

给 libjdufs_sdk.so、libgplcompression.so（那两个 (deleted) JNI so）补同版本的符号或 .debug。

把“哪一个 .so 的哪一个偏移”钉住（必要时用基址→偏移→addr2line）：

bash
# 基址看 info sharedlibrary 的 From
addr2line -fe /path/to/libxxx.so 0x<fault_offset>

拼日志时间线：

你已经在 NT_FILE 看到了 application_... 和 container_...：

bash
yarn logs -applicationId application_... \
          -containerId   container_... > container.log

搜 hs_err_pid*.log 看 Problematic frame。

在测试/预发用 ASan/UBSan（或 Valgrind）复现，抓第一次非法写的位置。

如果你把 gdb 里的 p $_siginfo 结果和 frame 12 的 info args/locals（去敏）贴一下，我可以直接判断你这个更像空指针还是野指针/堆损坏，并给出“在 doRecv 里该加哪几处边界/空值校验”的具体建议。

Answer 7

给的这些栈和 readelf 线索已经很关键了。我把你贴出来的结果“逐个拆解 + 落地招式”给你：

你现在这份 core 的关键信息（先下结论）

这是 Java 进程（/export/App/jdk1.8.0_60/bin/java）崩溃，HotSpot 走了标准的 fatal error 路径（raise → abort → libjvm.so: report_and_die()）。
事发线程的业务栈在 kunlun::netlib::TcpTransportExtend::doRecv 里调用 spdlog 过程中出错（#7–#12）。
#7 的地址是 0x7fe296c20ab7，这个地址落在你们的 SDK libjdufs_sdk.so 的映射区间里（不是“spdlog 动态库”——spdlog 是 header-only，被编进了你的 so 里）。
- libjdufs_sdk.so 加载起始（基址）≈ 0x7fe296a12000
- 偏移 = 0x7fe296c20ab7 - 0x7fe296a12000 = 0x20eab7
- 👉 用这一偏移就能 addr2line 精确到源码行（前提：有调试符号）。

为什么 `frame 12` 提示 “No such file or directory”？

gdb 里已经有行号信息（所以显示了 tcp_transport_extend.cpp:421），但你的分析机上没有这条路径对应的源码。

解决（任选其一）：

把同一版本的源码放到相同路径；或

用路径替换把“构建机路径 → 本机源码路径”映射起来：

gdb
(gdb) set substitute-path /export/code2/ljd/testrepo/src /home/me/src
(gdb) dir /home/me/src
(gdb) f 12
(gdb) list

如果仍无源码，走“基址→偏移→addr2line”：

bash
# 基址看 info sharedlibrary 的 From（或 readelf NT_FILE 的 Start/End）
addr2line -fe /export/Data/tmp/hadoop-tmp/libjdufs_sdk.so 0x20eab7

-f 可同时给出函数名。

为什么你看不到 `si_signo/si_addr`？

readelf -n 只告诉你“有一个 NT_SIGINFO 块”，不会展开字段。

在 gdb 里看才是正解：

gdb
(gdb) p $_siginfo                  # 打印 siginfo_t
(gdb) p $_siginfo.si_signo         # 信号号：SIGSEGV/SIGBUS/SIGABRT...
(gdb) p $_siginfo._sifields._sigfault.si_addr   # 出错访问地址（不同平台字段名略异）

你试的 $NT_FILE、$nt_file 不是 gdb 的“便利变量”，所以是 void——只有 $_siginfo 这个是内置的。

判别空/野指针：

si_signo=SIGSEGV 且 si_addr=0x0 → 空指针概率极高；

si_addr 是个怪地址、又不在任何映射内 → 野指针/越界写概率高；

SIGABRT → 多为主动 abort()（断言失败/堆损坏），去容器日志或 hs_err_pid*.log 看 fatal 文字更快。

4 个 gdb 动作，帮你把“到底错在谁、哪一行”钉死

确定信号与地址

gdb
(gdb) p $_siginfo
(gdb) info registers         # 看 $pc（RIP）、参数寄存器（RDI/RSI/...）

看事发帧的参数/局部
```
gdb
(gdb) f 12
(gdb) info args
(gdb) info locals
(gdb) p this
(gdb) disassemble /m $pc-32, $pc+64
```
- 变量被标成 <optimized out>：说明二进制是 -O2 且没带完整调试符号。要想看见更多变量，需要补符号（见下）。

确认库 + 偏移 + 行号

gdb
(gdb) info sharedlibrary | grep -n 'libjdufs_sdk.so'
# 记下 From 基址（≈ 0x7fe296a12000）
# 计算 offset，然后：
addr2line -fe /export/Data/tmp/hadoop-tmp/libjdufs_sdk.so 0x20eab7

拼容器/JVM 日志时间线（你已经有 appId/containerId）

bash
yarn logs -applicationId application_1754969617538_4473 \
          -containerId   container_e41_1754969617538_4473_01_000127 > container.log
# 如果启用了 JVM 错误文件：
find /export -name 'hs_err_pid*.log' -mmin 180

hs_err 里会有 Problematic frame: ... in libjdufs_sdk.so+0x20eab7 之类的直接证据。

“补符号”到底要做啥（超简要）

你的 info locals 大量 <optimized out>，而且 info sharedlibrary 里很多是 Yes (*) 或 No。
需要：
1. 系统库：安装 debuginfo（例如 glibc、libstdc++、zlib 等）。
2. 自家库（尤其 libjdufs_sdk.so、libgplcompression.so 那个已删除的临时 so）：把同一构建的 .debug 文件或未 strip 版本放到分析机：
```
gdb
(gdb) set debug-file-directory /path/to/debug-repo
(gdb) set solib-search-path     /path/to/so-repo
```
3. 下次构建尽量启用：-g -O1 -fno-omit-frame-pointer（线上可 strip，debug 包单独存）。

“动态链接 / .so / Java 怎么调 .so / 为什么 strip”一段话讲清

动态链接：可执行在运行时由动态链接器把依赖的 .so 按页映射到本进程虚拟地址空间，函数调用靠符号解析（PLT/GOT）跳到正确地址。
.so：ELF 共享库文件。可被多个进程共享，代码段只读共享。
Java 调 .so：走 JNI/JNR/JNA，如 System.loadLibrary("hadoop") / System.load("/abs/path/libxxx.so")，然后 native 方法跳到 C/C++ 实现。
为什么 strip：减体积/减少符号泄漏；分析时就需要把同版本 .debug 文件“补”回来。

“虚拟地址空间 & 加载基址”两句话

同一进程里，每个 .so 被映射到不同的地址区间（你在 NT_FILE 里看到了 Start/End），这就是“虚拟地址空间”的局部视图。
ASLR 让每次基址不同，所以定位库内崩溃点要用“基址 + 偏移”；addr2line 接受的就是偏移。

可能的根因方向（结合你这条栈）

错误发生在 doRecv →（warn 级别）spdlog 打日志这个链路里。
典型高发：
- 空/野指针作为日志参数（string_view/%s 指向已释放/未初始化内存）；
- 对缓冲区的越界写更早发生，稍后spdlog 读到坏内存时崩（“早写晚崩”）。
你要做的就是：
1. 用 $_siginfo 判别信号/地址；
2. 在 f 12 看参数/局部（补符号后效果更好）；
3. 用 addr2line 把 0x20eab7 精确到源码；
4. 看容器日志/hs_err 的异常文案；
5. 在测试/预发用 ASan（-fsanitize=address）+ UBSan 复现，这能把“第一次非法写”当场报出来（而不是等到 spdlog 才爆）。

你可以直接执行的 8 行指令

gdb
# 1) 打开 core
gdb /export/App/jdk1.8.0_60/bin/java /path/to/core
# 2) 看信号
p $_siginfo
# 3) 切到业务帧
f 12
info args
info locals
# 4) 算偏移（基址用你机器上的值替换）
#    例如：0x7fe296c20ab7 - 0x7fe296a12000 = 0x20eab7

bash
# 5) 映射到源码行（需要对应调试符号）
addr2line -fe /export/Data/tmp/hadoop-tmp/libjdufs_sdk.so 0x20eab7

# 6) 拉容器日志
yarn logs -applicationId application_1754969617538_4473 \
          -containerId   container_e41_1754969617538_4473_01_000127 > container.log

# 7) 找 hs_err
find /export -name 'hs_err_pid*.log' -mmin 180

# 8)（准备预发复现）用 ASan/UBSan 重编/重跑
CXXFLAGS="-g -O1 -fno-omit-frame-pointer -fsanitize=address,undefined"

如果你跑出了 p $_siginfo 的三项（si_signo/si_code/si_addr）和 addr2line 的行号，我可以再帮你“拍板”：这是更像空指针、野指针/越界还是堆损坏/主动 abort，并给出在 doRecv 这段代码里要加的2–3个具体防护检查（参数判空、长度边界、所有权/生命周期校验）的位置。

Answer 8

好消息：你已经把“信号现场”和“业务栈”都拿到了，现在可以下清晰结论并推进到精确定位哪一行了。下面我把你这次的输出解读、结论、以及下一步“落地动作”给全了。

1) 先读你给的关键信息（结论）

`p $_siginfo`

text
si_signo = 6
si_code  = -6
_sigfault.si_addr = 0x3aa66b

si_signo=6 → SIGABRT（终止信号），不是 SEGFAULT。
si_code=-6 在 Linux 上通常对应 SI_TKILL（线程自发的信号，常见于 abort()/tgkill() 路径）。
对于 SIGABRT，_sigfault.si_addr 没有诊断意义（那是给 SEGV/BUS 用的出错访问地址）。所以这里的 0x3aa66b 不必解读。

回溯（`bt`）

text
#0 raise → #1 abort → #2 os::abort → #3 VMError::report_and_die
#4/#5 JVM_handle_linux_signal/signalHandler
#6 <signal handler called>
#7~#12 spdlog → kunlun::...::doRecv()

HotSpot 的致命错误处理已接管，然后调用 abort() → 所以 core 的终止信号是 SIGABRT。
真正触发致命错误的“最初原因”不在当前信号字段里，通常写在 hs_err_pid*.log 里（Problematic frame、原始 SIGSEGV/SIGBUS、或堆损坏等信息）。
也可能是 glibc 自检（如 malloc(): memory corruption）触发了 abort，这类文案会出现在容器 stdout/stderr 或 hs_err 里。

业务帧

#12 kunlun::netlib::TcpTransportExtend::doRecv(...):421

gdb 知道行号，但本机没有源码路径（所以提示 No such file or directory）。
局部变量大多 <optimized out> → 需要补调试符号才能看到更多细节。

2) 把“崩溃点”钉到具体源码行（不依赖本机源码路径）

你可以直接把第 7 帧的地址换算成 libjdufs_sdk.so 内偏移，再 addr2line 还原行号：

第 7 帧地址：0x7fe296c20ab7
从你之前的映射看，libjdufs_sdk.so 的加载基址约为：0x7fe296a12000
偏移：0x7fe296c20ab7 - 0x7fe296a12000 = 0x20eab7

bash
addr2line -fe /export/Data/tmp/hadoop-tmp/libjdufs_sdk.so 0x20eab7
# -f 显示函数名，-e 指定库文件

这样即使你没有把源码放回相同路径，也能直接得到“库内偏移 → 源文件:行号”。
若这一步报不出行号，说明 libjdufs_sdk.so 缺调试符号：把同版本的 .debug 文件放到分析机（或不 strip 的 so），然后重跑。

3) 为什么是 SIGABRT？“空/野指针”还怎么判断？

当前 core 的终止信号是 SIGABRT（abort()）。abort 的常见来源：
1. HotSpot 捕获了原始的致命信号（如 SIGSEGV）后，打印 fatal 报告，最后 abort()；
2. glibc/库自检触发（堆损坏、断言失败等），直接 abort()；
3. 代码显式 abort()。
因为是 SIGABRT，si_addr 对“判空/野指针”不再适用。想知道原始错误是“空/野指针/堆损坏”，需要：
- 找 hs_err_pid*.log：里面会写 A fatal error has been detected...、Problematic frame:、EXCEPTION_ACCESS_VIOLATION/SIGSEGV 等原始信息；
- 查容器日志里崩溃前的 stderr：是否出现 malloc(): memory corruption、double free、*** buffer overflow detected *** 等字样。

你已经通过 NT_FILE 拿到了 applicationId/containerId，直接拉日志：

bash
yarn logs -applicationId application_1754969617538_4473 \
          -containerId   container_e41_1754969617538_4473_01_000127 \
          > container.log
find /export -name 'hs_err_pid*.log' -mmin 240

4) “No such file or directory”怎么解决（让 gdb 能显示源码）

任选一种：

把对应版本源码同步到相同路径：/export/code2/ljd/testrepo/src/...

用路径替换（推荐）：

gdb
set substitute-path /export/code2/ljd/testrepo/src /home/andrew/src
dir /home/andrew/src
f 12
list

不折腾路径，直接走 addr2line（上面已经给出）。

5) 变量都是 `<optimized out>` 怎么办（“补符号”的落地）

现象：info locals 里大量 <optimized out>，说明编译用了 -O2 且没有完整 DWARF。
解决：
- 系统库：安装 debuginfo 包（glibc、libstdc++、zlib…），这样能看更清楚的系统栈。
- 自家库（重点是 libjdufs_sdk.so）：把同一构建的 .debug 放到分析机，并让 gdb 能找到：
```
gdb
set debug-file-directory /path/to/debug-repo
set solib-search-path   /path/to/so-repo
```
- 下次构建建议：-g -O1 -fno-omit-frame-pointer（线上可 strip，调试符号单独存 Build-ID 仓）。

6) 现在就可以做的 6 步 SOP（你几乎都准备好了）

确认终止信号（你已做）
→ SIGABRT（si_signo=6），si_addr 忽略。

将崩溃点指到源码行（即使没源码路径）

bash
addr2line -fe /export/Data/tmp/hadoop-tmp/libjdufs_sdk.so 0x20eab7

查看容器/JVM fatal 文案（原始原因多在这里）
```
bash
yarn logs ... > container.log
find /export -name 'hs_err_pid*.log' -mmin 240
```
- 若看到 SIGSEGV at 0x0/EXCEPTION_ACCESS_VIOLATION → 大概率空指针；
- 若看到 malloc(): memory corruption/double free → 堆损坏；
- 若有 assert(...) failed → 断言触发。

补符号后再次查看第 12 帧

gdb
f 12
info args
info locals
p this
# 结合源码，检查传入的 buffer 指针/长度/生命周期

排查“日志参数”是否有问题
- 你的栈显示崩在 spdlog::logger::log_* 这一侧。常见坑：日志格式字符串引用了无效内存（空/野指针），或 fmt 的参数类型与实际不符。
- 在 doRecv/上游调用点增加保护：
  - 对所有 const char*/string_view 参数判空；
  - 对长度/边界校验；
  - 避免把悬垂引用（指向临时对象的引用/指针）传给日志。
在测试/预发用 Sanitizer 抓“第一次非法写”（如果容器日志提示堆损坏/随机崩）
- 重新编译可执行/so：
```
-g -O1 -fno-omit-frame-pointer -fsanitize=address,undefined
```
- 运行复现用例：ASan/UBSan 会在第一次非法访问时立刻报栈，而不是等到 spdlog 时才崩。

快速问答（对你现阶段最关键的几个点）

这是空指针/野指针吗？
仅凭这个 core：不能直接下结论，因为终止信号是 SIGABRT。请以 hs_err_pid*.log/容器日志 为准；若日志显示原始 SIGSEGV at 0x0 → 空指针概率大。
为什么要算偏移再 addr2line？
因为 ASLR 让每次“加载基址”不同。fault_ip - base = offset 是定位库内源码行的稳定方法。
为什么 gdb 说没文件？
行号信息在，但本机没那条路径的源码。用 set substitute-path 或直接 addr2line。

把 addr2line 的结果（函数 + 行号）和 容器/hs_err 日志中的 fatal 文案贴出来（去敏即可），我就能帮你把根因进一步收敛到“空指针/越界/堆损坏/断言”的哪一类，并给到你在 doRecv 附近该加的 2–3 条具体防御性检查（参数判空、长度校验、所有权/生命周期约束）的代码位点。

问题

思考

Explaining core files

Analyzing core dumps with Java and C++

Handling core dump files

Debugging core dumps

回答

什么是 core file

core 里包含什么

core 何时会（不会）生成

开启与存放位置

如何触发/收集一个 core（用于验证流水线）

分析 core 的常用流程（C/C++）

A. systemd-coredump 场景（推荐）

B. 传统 core 文件

关键要点

Java / JNI / Hadoop 相关

你们组可落地的巡检/排障清单

常见“为什么没产 core”的坑

辅助工具与技巧

问题

思考

Providing core dump guidance

Providing Yarn logs playbook

Explaining core dumps and analysis tools

Explaining core limits and crashes

Explaining crash and core analysis

回答

1) 为什么会有 core，它从哪儿来？

2) 我们现在是怎么“存储 core”的？配在哪儿看？

A) 系统级（对整机上所有进程生效）

B) 服务/用户级（覆盖“是否允许写”和保留路径）

3) 从“一个 core 文件”如何定位到“哪个进程/哪台容器/看哪儿的日志”

如果机器上启用了 systemd-coredump（core_pattern 以 |...coredump 开头）

如果是“传统 core 文件”（直接落成文件）

4) 传统 core vs systemd-coredump（对比速览）

5) “为什么进程会自己崩溃？”（几类典型）

6) “寄存器/映射/ELF notes”该怎么读？（做最必要的）

7) “native 崩溃是怎么崩？”（JNI 相关高频坑）

8) “C++ 的 SDK 会不会很难、是不是到处都是指针？”

9) 哪些“非核心问题”先记录、不阻塞主流程？

10) 你可以直接抄用的命令串（SOP 迷你版）

问题

思考

Explaining readelf and GDB output

Explaining gdb commands and YARN logs

Analyzing readelf NT_FILE output

Interpreting libraries and symbols

Explaining commands and libraries

回答

1) readelf -n core.xxx（读 core 里的 ELF notes）

2) gdb 里的四条命令

a) set pagination off

b) info sharedlibrary

c) thread apply all bt

d) info registers