clion支持通过run | open core dump加载core dump（linux/macos）或minidump（windows，路径通常为%localappdata%\crashdumps），但需确保调试器匹配（windows minidump仅支持lldb）、符号文件正确指定（gdb必需，lldb推荐）、且可执行文件含调试信息（cmake_build_type=debug）。
CLion 里程序一跑就崩溃，不是代码写错了，大概率是调试环境没对上——尤其是核心转储（core dump）或 minidump 没配对符号、调试器选错、或者根本没生成调试信息。
崩溃后怎么打开 core dump 文件
CLion 支持直接加载 Linux/macOS 的 core 文件和 Windows 的 minidump（路径通常在 %LOCALAPPDATA%\CrashDumps），但必须手动触发：
- 用
Run | Open Core Dump菜单，或按Ctrl+Shift+0 A打开Find Action，搜 “Open Core Dump” - 如果项目里已有 Core Dump Debug 配置，会先弹出选择菜单；否则直接进文件选择对话框
- 选中 dump 文件后，CLion 会尝试自动匹配二进制——若失败，下一步必须手动指定符号
为什么打开 core dump 后看不到源码行、变量全是问号
因为 LLDB/GDB 找不到原始可执行文件的调试符号。这不是 CLion 的 bug，是符号路径没对齐：
- LLDB 可以“猜”二进制位置，但只在 dump 里存了模糊路径时才靠谱；GDB 则完全不猜，必须人工指定
- 在 Core Dump Debug 配置里，
Symbol file字段必须填：./cmake-build-debug/myapp（未剥离的 debug 版本），不能填./cmake-build-release/myapp - 如果用了分离符号（如
.debug文件），得把那个文件路径也加进Symbol Paths设置里（Run | Edit Configurations → Core Dump Debug → Symbol Paths）
调试器选 LLDB 还是 GDB？Windows 上特别注意
选错调试器会导致 core dump 根本加载失败，甚至 IDE 卡死：
- Linux/macOS：优先用
bundled LLDB，它对 core dump 的兼容性更稳，支持冻结线程等高级操作 - Windows minidump：只能用 LLDB（MSVC 工具链自带的 LLDB），GDB 选项是灰色的——文档明确写了 “Windows minidumps can't be debugged with GDB”
- 如果强行在 Windows 上选 GDB，CLion 会静默跳过加载，连错误提示都不给；此时看
Debug工具窗口右上角状态栏，会显示 “No debug session”
崩溃前没留 core dump？那就得提前开捕获
靠事后抓 dump 是被动的；真要稳定复现，得让系统在崩溃时自动生成：
- Linux：运行前执行
ulimit -c unlimited，并确认/proc/sys/kernel/core_pattern指向可写路径（比如/tmp/core.%e.%p） - macOS：默认禁用 core dump，需执行
sudo sysctl -w kern.corefile=/tmp/core.%P+ulimit -c unlimited - Windows：用注册表或 WER（Windows Error Reporting）配置 minidump 生成，路径务必加进 CLion 的
Symbol Paths，否则照样白忙
最常被忽略的一点：CMake 构建时没开 -g，即使 dump 和二进制都对上了，看到的也是汇编和地址，没有变量名和行号——CMAKE_BUILD_TYPE 必须设为 Debug，且不能被 RelWithDebInfo 或其他宏覆盖掉。
