CLion调试时程序崩溃通常源于调试环境与运行环境不一致，如符号缺失、时钟干扰、core dump路径错误或调试器超时；应先在终端用lldb/gdb复现，再针对性检查OpenOCD配置、CMake的-g选项、符号路径、权限及超时设置。
CLion 调试时程序崩溃，不是必须重启 IDE 或重写代码——绝大多数情况是调试上下文与实际运行环境不一致导致的，比如符号缺失、时钟干扰、核心转储路径错误或调试器超时。先确认崩溃是否可复现于终端调试器，再针对性处理。
崩溃发生在调试启动阶段（还没进 main）
常见于嵌入式（如 STM32）或带硬件初始化逻辑的项目。OpenOCD/GDB 在 reset-init 阶段会提前配置 PLL，导致 SystemClock_Config 中重复配置失败并卡死在 HAL_ERROR。
- 检查 OpenOCD 配置脚本中是否有
reset-init事件修改了时钟寄存器（如mww 0x40023800 0x01000000） - 将 CLion 的 GDB Server 启动选项改为
-ex "monitor reset halt"+-ex "monitor init"，跳过自动时钟提升 - 或在
main()开头加__HAL_RCC_CLEAR_RESET_FLAGS();清除复位标志，避免 HAL 库误判
崩溃后无法加载源码或变量显示 error: summary string parsing error
说明调试器读到了内存数据，但找不到匹配的符号或类型定义。LLDB 尤其容易在缺少调试信息或模板实例化深度大时出错。
- 确保 CMake 构建时启用了
-g且未启用-fno-rtti或-fno-exceptions（除非你明确不需要） - 在 CLion 的
Run → Edit Configurations → Debug → Symbol Paths中添加./cmake-build-debug和所有依赖库的未剥离二进制路径 - 遇到字符串解析错误时，在
lldb控制台手动执行settings set target.max-string-summary-length 1024，或在~/.lldbinit中持久化
崩溃生成了 core dump，但 CLion 打开后显示 no debug info
核心转储本身不带符号，CLion 必须通过外部二进制或 .debug 文件还原上下文。GDB 对符号路径更敏感，LLDB 可自动关联但需二进制未被 strip。
- 用
file ./cmake-build-debug/myapp确认输出含with debug_info；若为stripped，重新构建并检查 CMakeLists.txt 是否有set(CMAKE_BUILD_TYPE "Debug") - Linux/macOS 下，core 文件默认权限为 600，CLion 需要读取权限：
chmod 400 core.1234 - 不要把
.so文件设为“Symbol file”——LLDB/GDB 会尝试从文件偏移解析地址，而非内存地址，导致堆栈错乱
调试器报 Command timed out 或直接断连
不是网络问题，而是 CLion 后端等待调试器响应超时。尤其在大型项目、高优化代码或内联函数密集处，变量求值/堆栈展开耗时剧增。
- 打开
Help → Find Action → Registry，搜索cldr.debugger.timeout，调高到120000（2 分钟） - 禁用耗性能的调试辅助：在
Settings → Build → Debugger → Data Views → Pointers中取消勾选Enable pointer view - 如果使用 GDB，添加
-ex "set follow-fork-mode child"到调试器额外选项，避免 fork 后丢失子进程上下文
真正难排查的崩溃往往藏在“调试器比运行时多做了什么”里——比如 OpenOCD 提前改时钟、GDB 加载了错误版本的 libstdc++、LLDB 从 stripped 的 so 里硬解析符号。别急着换工具链，先用 lldb ./binary 在终端复现，对比行为差异，那才是问题真正的分水岭。
