core文件本身不记录运行目录，GDB中pwd显示的是当前路径而非崩溃时cwd；需用info proc cwd查看（要求Linux内核≥2.6.20且core未截断），否则应依赖core_pattern路径规范或启动日志还原。
core文件本身不记录运行目录
直接看 core 文件，它不保存程序启动时的 cwd（current working directory）。GDB 读取 core 后，pwd 命令显示的是你当前 GDB 所在的路径，不是崩溃时的路径。
用 info proc cwd 查看崩溃时工作目录
前提是：core 是在 Linux 上生成、且内核版本 ≥ 2.6.20、未被截断或损坏。GDB 加载后执行：
gdb ./myapp core-12345 (gdb) info proc cwd
如果支持，会输出类似：
cwd = '/home/user/project'
常见失败原因包括：
-
core_pattern配置中用了相对路径，但生成时进程已 chdir - 容器环境（如 Docker）中
/proc被隔离，info proc不可用 - core 文件太小（
ulimit -c设得太低），导致/proc/[pid]/cwd符号链接信息丢失
从 core 文件名反推运行目录（最常用）
多数团队会把 core_pattern 设成带路径的格式，比如：
echo "/var/coredumps/core-%e-%p-%t" | sudo tee /proc/sys/kernel/core_pattern
此时 core 文件本身虽不存 cwd，但它的**存放位置**就是人工指定的统一路径，和运行目录无关；而文件名里的 %e（程序名）、%p（PID）、%t（时间戳）能帮你快速定位是哪个实例、何时崩溃。
真正需要还原原始运行目录时，更靠谱的做法是：
- 在启动脚本里显式记录：
echo "started at $(pwd)" >> /var/log/myapp.log - 用
systemd服务时，在.service文件里加WorkingDirectory=并启用LogLevel=debug - 崩溃前调用
getcwd()写入日志（需代码配合）
为什么别依赖 ls -l /proc/[pid]/cwd 查历史？
进程崩溃后，/proc/[pid] 目录立刻消失，无法回溯。唯一能留下的线索，就是 core 文件生成时是否被完整捕获了 procfs 中的元数据——而这只在 GDB 的 info proc 支持且 core 未被裁剪时才有效。实际排障中，靠日志+命名规范比靠 runtime 状态更稳。
