条件断点、数据断点、attach到运行进程、调用栈与汇编视图交叉验证是qt creator高效定位内存泄漏等疑难问题的四大核心技巧，需组合使用并注意后端配置等细节。

用条件断点代替无脑F10/F11

单步执行（F10）和步入（F11）在函数调用浅、逻辑线性时还凑合，一旦遇到循环内频繁分配内存、信号反复触发或后台线程轮询，就容易陷入“按十几次才等到关键路径”的窘境。条件断点才是真解法。

• 右键已有断点 → 选择“Edit Breakpoint…” → 在 Condition 栏填入表达式，比如 ptr == nullptr 或 i > 1000
• 支持完整C++表达式，但避免调用可能改变状态的函数（如 qDebug()），否则断点行为不可预测
• 对 Qt 容器操作特别有用：在 QList::append 前加条件 size() > 10000，能跳过前9999次噪音

给关键内存地址打数据断点（Watchpoint）

内存泄漏或野指针改写，往往不是“在哪崩”，而是“谁偷偷动了这块内存”。这时候普通断点完全失效，必须用数据断点监控读写。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• 调试状态下，打开 Locals and Expressions 面板 → 右键变量（如 dataPtr）→ “Add Watch Expression” → 再右键该监视项 → “Change Value Type” → 选 Watchpoint
• 注意：仅支持原生指针或全局/静态变量地址；QSharedPointer 或栈对象地址无法设
• Windows 下需启用 WinDbg 后端（Tools → Options → Debugger → GDB/LLDB → Use WinDbg backend），否则数据断点不生效

Attach 到运行中的进程抓偶发问题

有些崩溃只在用户操作半小时后出现，或者依赖特定网络延迟、传感器输入——等你手动启调试再复现？基本不可能。直接 attach 才是正解。

• 运行你的程序（非调试模式），让它走到可疑状态（比如内存已涨到800MB）
• 菜单栏 Debug → Start Debugging → Attach to Running Application… → 从列表选中你的进程
• attach 后立刻在疑似泄漏点（如 TreeNode::removeChild）打条件断点，无需重启，状态全保留
• Linux/macOS 下需确保进程未被 ptrace 限制；若提示“Permission denied”，用 sudo sysctl -w kernel.yama.ptrace_scope=0 临时放开（仅开发机）

调用栈 + 汇编视图交叉验证空指针

当 Segmentation fault 发生但 C++ 层没明显错误时，问题常藏在 Qt 元对象系统或隐式转换里。光看 C++ 调用栈不够，得下钻到汇编层确认真正出事的指令。

• 崩溃暂停后，切换到 Registers 和 Disassembler 面板（View → Views → Registers / Disassembler）
• 找 mov 或 call 指令中使用的寄存器值（如 rax 是 0），再回溯到上一行 C++ 行号
• 特别注意 Qt 的信号槽连接：如果用 Qt::DirectConnection 连了跨线程对象，崩溃栈顶常显示 QMetaObject::activate，但真正问题在槽函数内部的 this 已释放

Qt Creator 的调试效率瓶颈，从来不在按钮多寡，而在是否主动放弃“跟着代码走”的惯性思维——条件断点、数据断点、attach、汇编视图，四者组合使用时，才真正把调试从“碰运气”变成“查证”。最常被忽略的是：数据断点在默认 GDB 后端下几乎无效，而 attach 后忘了关掉“Load symbols automatically”会导致卡顿十几秒——这些细节不调，再快的硬件也白搭。