如果一个程序跑10000次只失败一次，你会怎么调试？

最新推荐文章于 2025-05-20 09:40:15 发布
最新推荐文章于 2025-05-20 09:40:15 发布
阅读量3.2w 收藏 90
点赞数
CC 4.0 BY-SA版权
分类专栏： WinDbg 文章标签： null 测试 access ui c
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ATField/article/details/4493003
这篇博客介绍了在程序运行多次才出现一次错误时的调试方法。通过使用CDB（WinDbg的无UI版本）设置硬件数据断点和条件断点，反复执行程序，收集错误发生时的日志，从而定位问题。文中以一个示例说明了如何在10000次运行中捕捉到仅出现一次的错误，强调了这种方法在复杂程序和大规模测试中的适用性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

CLR小组中存在着大量的回归测试，这些回归测试会定期执行来发现CLR中的Bug，Developer在Checkin之前，也需要执行这些测试的一部分（大概是10小时左右，如果全部跑的话估计要好几天）。这些测试对于保证CLR的质量是至关重要的。有时候，这些测试会偶尔失败，比如跑100次失败大概一到两次，有些极端的例子甚至是10000次才失败一次。像这种问题通常是很难调试的。在前面调试Bug的神兵利器：通过WinDbg条件断点收集Log这篇文章中，我讲到了如何通过条件断点收集各种信息来判断Bug究竟出在哪里。但是，这个方法还是不太管用，因为它不能够反复执行某个程序。下面我要讲一种技巧可以用来调试类似这样的问题，这种技巧主要适用于下面几种情况：

  1. 在程序出错的时候，某些信息、状态已经丢失，无法通过当前出错时候的状态推断出之前的状态。说的稍微具体一点就是，比如某个变量变成了NULL导致Access Violation，但是很难直接推断出为什么这个变量变成了NULL
  2. 程序运行时间较长，很难直接单步调试
  3. 程序较难修改加入打印代码（比如加入新代码并编译非常花时间，或者该程序没有源代码
  4. 该程序运行次数较多的时候才能发现问题，也就是说问题不是每次都出现

#2和#4决定了一步步调试基本上是不可能的。#1和#3则意味着我们必须得使用条件断点来收集信息来判断代码的错误，因为直接调试出错的位置是不可行的。下面了我来讲一下如何用CDB（其实就是WinDbg的无UI版本，WinDbg=CDB+UI）来做到：

  1. 反复执行程序
  2. 当程序出错的时候自动暂停
  3. 通过条件断点收集信息，只保留出错时候的那一次Log

我们先假设我们需要调试的程序叫做Hello.exe，每次出问题的现象是，调用某个函数Hello!Func()的时候，其参数arg为NULL。Arg这个变量是由某个全局变量g_arg传入而来。我们可以通过硬件的数据断点来查看

最低0.47元/天 解锁文章

200万优质内容无限畅学
【C++软件异常排查实战经验分享系列 ②】查看函数调用堆栈 | Windbg动态调试 | DLL动态库加载失败 | API Monitor工具 | 程序闪退 | 寻找dump文件 | GDI对象泄漏
dvlinker的技术专栏
06-30 1万+
在开发调试C++软件的过程中会遇到各式各样的问题，通过排查这些项目问题可以积累大量的实战排查经验和处理技巧，本文对这些经验和技巧做个总结和分享，以供大家借鉴或参考。
C++程序发生闪退且没生成dump文件问题的排查经验总结与分享
热门推荐
dvlinker的技术专栏
10-14 2万+
本文详细讲述了C++程序发生闪退且没有生成dump这类问题的场景及排查方法，并给出了相关实战问题分析实例，有一定的实战参考价值。
解决一个平均运行一百万次才出现一次的bug
Eric的专栏
11-10 2599
在多线程和高并发环境下，如果有一个平均运行一百万次才出现一次的bug，你如何调试这个bug？ http://dbaplus.cn/news-21-625-1.html 作者给出了一个实际的例子，和解决方法。 1. 明确的辨析出问题现象。 异常，CoreDump，出现问题的时间点。这也依靠程序的日志，才能找到相关的点。 2. 明确触发问题的路径。 可能是一些相关的操作，比如，可
从C++软件调试实战的角度去看多线程编程中的若干细节问题
dvlinker的技术专栏
11-12 1万+
本文从C++软件调试实战的角度去讲述多线程编程中的若干细节问题，并给出了具体的问题分析实例。
【C++软件实战问题排查经验分享系列 ④】pdb符号文件 | dump文件分类与生成方法 | Windbg分析dump文件 | Windbg动态调试 | Windbg常用命令 总结
最新发布
dvlinker的技术专栏
05-20 3万+
在开发调试C++软件的过程中，时常会使用Windbg分析排查软件运行过程中遇到的各种异常问题。本文对使用Windbg涉及到的pdb符号文件、dump文件分类与生成方法、Windbg分析dump文件、Windbg动态调试目标进程、Windbg常用命令等诸多相关内容进行详细的总结，并给出相关的实战分析实例，供大家借鉴或参考。
不能设置断点的检查步骤
王伟挺的专栏
05-15 1181
在调试程序的时候，有的时候你会发现设置的断点不起作用，而且更糟糕的是，一般碰到这种情况的时候都是非常紧急或者是加班到夜已深、人寂静的时候了。正是应了那句玩笑话：“机器机器，越急越气!”。一般发生断点不起作用的话： 1.         你首先要判断的是断点是否真的设置上了？ a)         如果在Visual Studio里面，你的断点符号是一个实心圆，那么断点的确是设置上了，你要判断的
Java进行一万次求和循环，并输出循环过程，并做了速度优化
Yangchenju的博客
11-20 5827
1. 问题 本文接我的上一篇文章：Java输出进行十亿次循环的耗时（2） 在上一篇文章中发现的问题是：当在特别大的循环语句（指循环次数特别大）中出现System.out.print()语句时，程序执行的速度十分慢，就上一个例子，就需要花费17.6小时，本文优化了类似的问题。 2. 解决（举例） 本文通过对比的方式说明： 首先展示一万次求和并且打出印过程的耗时（为方便描述，这里我把它称为未优化） ...
深度学习中的epochs，batch_size，iterations
苦逼的程序猿
07-14 1278
batch 深度学习的优化算法，说白了就是梯度下降。每次的参数更新有两种方式。 第一种，遍历全部数据集算一次损失函数，然后算函数对各个参数的梯度，更新梯度。这种方法每更新一次参数都要把数据集里的所有样本都看一遍，计算量开销大，计算速度慢，不支持在线学习，这称为Batch gradient descent，批梯度下降。 另一种，每看一个数据就算一下损失函数，然后求梯度更新参数，这个称为随机梯度下降，stochastic gradient descent。这个方法速度比较快，但是收敛性能不太好...
debug练习一千次
grett的专栏
04-09 787
饭要一口一口的吃  路要一步一步地走 随便打的字 虽然很灰心  不过出版业从来都是慢慢来
alg-查找只出现一次的数
weixin_30273931的博客
08-05 177
//只有2个数出现1次，其余的数都出现2次 class Solution { public: vector<int> singleNumber(const vector<int>& nums) { int diff = accumulate(nums.begin(), nums.end(), 0, bit_xor<int&gt...
Bug严重度分类、测试结束标准、bug只出现一次的处理
zhusongziye的博客
08-31 4847
A类—严重错误，包括以下各种错误： 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 与数据库连接错误 6． 数据通讯错误 B类—较严重错误，包括以下各种错误： 1.程序接口错误 2.系统可被执行，但操作功能无法执行（含指令） 3.单项操作功能可被执行，但在此功能中某些小功能（含指
c++跑着崩溃
04-10
### C++ 程序运行时崩溃的原因及解决方法 C++ 程序在运行时可能会因为多种原因而导致崩溃。以下是常见的几种情况及其对应的解决方案： #### 1. 调试工具的应用 为了定位程序崩溃的具体位置，可以利用调试器（如 gdb）。通过设置断点并逐步执行代码，能够有效发现导致崩溃的逻辑错误或非法操作[^1]。 #### 2. 内存不足引发的新建对象失败 当程序尝试分配内存时，如果可用虚拟内存不足以满足需求，则会触发 `std::bad_alloc` 异常，进而造成程序终止。为了避免这种情况的发生，可以在创建大容量的对象之前检查系统的剩余内存状态，并设计合理的内存管理策略[^2]。 ```cpp try { int* largeArray = new int[SIZE]; } catch (const std::bad_alloc& e) { std::cerr << "Memory allocation failed: " << e.what() << '\n'; } ``` #### 3. 整数溢出问题 对于有符号整数类型（如 `int`），一旦其值超出可表示的最大范围，就会发生未定义行为，这可能是程序崩溃的一个潜在因素。因此，在涉及数值计算的地方应特别注意边界条件[^3]。 ```cpp #include <limits> ... if (value > std::numeric_limits<int>::max()) { throw std::overflow_error("Integer overflow detected."); } value++; ``` #### 4. 栈溢出风险 函数递归层数过深或是单次调用中声明了占据较大栈空间的局部变量都容易引起栈溢出现象。优化算法减少不必要的递归转换成迭代形式；另外考虑动态分配那些体积庞大的数组而非静态地置于堆栈之上[^3]。 ```cpp // 动态分配替代固定大小的大数组 void saferFunction() { const size_t LARGE_SIZE = 10000; int *largeArray = new int[LARGE_SIZE]; delete[] largeArray; // 记得释放资源 } ``` #### 5. 文件I/O 错误处理 无论是由于目标路径下缺失指定文档还是硬件层面诸如存储设备损坏等原因都会致使文件输入输出过程中的失误。所以每次完成相应动作之后都要验证结果是否成功，以便及时采取补救措施。 ```cpp std::ifstream inputFile("example.txt"); if (!inputFile.is_open()) { std::cerr << "Failed to open file." << std::endl; } std::ofstream outputFile("log.txt", std::ios::app); outputFile << "Logging data..." << std::flush; if (!outputFile.good()) { std::cerr << "Error writing to log file!" << std::endl; } ``` #### 6. 异常捕捉机制完善度 任何未经妥善处置就抛出来的异常都有可能让整个应用程序瞬间瓦解。为此建议全面覆盖可能出现的各种状况下的响应预案，确保即使遇到预料之外的情况也能维持基本功能运转正常。 ```cpp try { riskyOperation(); } catch(const std::exception& ex){ handleError(ex.what()); } finally{ cleanupResources(); // 如果支持finally语法的话 } ``` #### 7. 多线程环境下的同步控制 并发环境下不同进程间相互干扰也是常见事故源之一——比如竞态条件(race condition)，即两个以上线程同时更改同一份资料却缺乏必要的协调手段。引入锁(locking mechanism)或其他互斥技术可以帮助缓解此类矛盾冲突局面[^3]。 ```cpp std::mutex mtx; void safeThreadFunc(){ std::lock_guard<std::mutex> lock(mtx); ++sharedVariable; } ``` 问题
评论 46
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值