有了它，我在bug面前一点也不慌~

[导读]大家好，我是bug菌！最近看到一个小伙子调bug，那简直是苦不堪言，断点是打了无数个，日志是打印了一大堆。可想而知，这样调试bug的过程是痛苦的，特别是一些莫名其妙的bug。而更可恼的是，有时候项目、客户、boss还要在旁边催，估计大部分工程师都想一鼠标键盘砸过去了……不过，非常...

大家好，我是bug菌！最近看到一个小伙子调bug，那简直是苦不堪言，断点是打了无数个，日志是打印了一大堆。可想而知，这样调试bug的过程是痛苦的，特别是一些莫名其妙的bug。而更可恼的是，有时候项目、客户、boss还要在旁边催，估计大部分工程师都想一鼠标键盘砸过去了……
不过，非常时刻还是要有非常手段，毕竟有些bug是毁灭性的，动不动一个小时损失几W的场面那是多么可怕的。
我觉得解决bug主要是两个方面：
1、解决bug过程的思路一定要清晰，不要全凭感觉，东打一枪，西轰一炮，调试过程要有步骤有依据，更不要在代码中注释类似于"把这行代码屏蔽就可以正常运行这样的注释了~~"

2、理论知识要完备，包括问题的专业知识和高效的调试技巧知识，对这一块功能设计理解都不透彻怎么根除问题呢?
今天主要是跟大家介绍一下条件断点（统称，下面类似）如何使用，可以说有一半以上的软件工程师很少、甚至没有用过条件断点，这可是调试bug的神器，为何不好好利用起来呢？难道一定要一个个普通断点的调试才更带感吗？

Keil中的调试断点

我们可以找到Debug调试中的Breakpoints选项进入该工程中所有设置断点的具体信息：

上图展示了03和04两个断点，分时标注了用户所设置断点的位置。其实你完全可以把这种普通断点看成是条件断点的一种，其条件就是当程序运行到如上所设置的地址处就会终止运行，只是说这样的普通断点可以直接在所编写的程序中点击设置。

然而面对更加复杂的条件断点，似乎Keil并不能为用户更好的提供展示，也是就有了上图的断点设置对话框，但又担心我们不知道怎么用，于是就有了一个help跳转到帮助文档供我们查阅。

可以说在help里面几乎把每一项的功能都说得很清楚了，并且蓝色部分可以点击进入进一步详细说明，所谓“授人以鱼不如授人以渔”，bug就不啰嗦了，下面是help里面的实例，照着来即可~

不过，这里还是简单介绍一下Keil中为用户提供了三类断点：

访问断点(A)

此类断点是设置了读或写标志，或同时设置了这两个标志的时候使用的。当指定的内存访问发生时触发断点，这就非常有用了，有了它你调试程序的害怕数组越界吗？变量被篡改吗？

可以选择指定内存访问窗口的大小(以字节为单位)或作为表达式的对象大小。对于此断点类型，表达式必须解析为内存地址和内存类型，允许的操作符 (