中断和异常，C/C++语言异常，实时操作系统对中断和异常的处理

一、中断和异常是什么

在操作系统中引入核心态和用户态这两种工作状态后，就需要考虑这两种状态之间如何切换。操作系统内核工作在核心态，而用户程序工作在用户态。系统不允许用户程序实现核心态的功能，而它们又必须使用这些功能。因此，需要在核心态建立一些“门”，以便实现从用户态进入核心态。在实际操作系统中，CPU运行上层程序时唯一能进入这些“门”的途径就是通过中断或异常。发生中断或异常时，运行用户态的CPU会立即进入核心态，这是通过硬件实现的(例如,用一个特殊寄存器的一位来表示CPU所处的工作状态，0表示核心态，1表示用户态。若要进入核心态，则只需将该位置О即可)。中断是操作系统中非常重要的一个概念，对一个运行在计算机上的实用操作系统而言，缺少了中断机制，将是不可想象的。原因是，操作系统的发展过程大体上就是一个想方设法不断提高资源利用率的过程，而提高资源利用率就需要在程序并未使用某种资源时，把它对那种资源的占有权释放，而这一行为就需要通过中断实现。

1. 中断和异常的定义

中断(Interruption)也称外中断，指来自CPU执行指令以外的事件的发生，如设备发出的IO结束中断，表示设备输入/输出处理已经完成，希望处理机能够向设备发下一个输入/输出请求，同时让完成输入/输出后的程序继续运行。时钟中断，表示一个固定的时间片已到，让处理机处理计时、启动定时运行的任务等。这一类中断通常是与当前指令执行无关的事件，即它们与当前处理机运行的程序无关。

关于内中断和外中断的联系与区别：

异常（Exception）也称内中断、例外或陷入( trap),指源自CPU执行指令内部的事件,如程序的非法操作码、地址越界、算术溢出、虚存系统的缺页及专门的陷入指令等引起的事件。对异常的处理一般要依赖于当前程序的运行现场，而且异常不能被屏蔽，一旦出现应立即处理。

2. 中断处理的过程

不同计算机的中断（指外中断）处理过程各具特色，就其多数而论

1)关中断。CPU响应中断后，首先要保护程序的现场状态，在保护现场的过程中，CPU 不应响应更高级中断源的中断请求。否则，若现场保存不完整，在中断服务程序结束后，也就不能正确地恢复并继续执行现行程序。

2）保存断点。为保证中断服务程序执行完毕后能正确地返回到原来的程序，必须将原来的程序的断点（即程序计数器PC）保存起来。

3）中断服务程序寻址。其实质是取出中断服务程序的入口地址送入程序计数器PC。

4)保存现场和屏蔽字。进入中断服务程序后，首先要保存现场，现场信息一般是指程序状态字寄存器PSWR和某些通用寄存器的内容。

5）开中断。允许更高级中断请求得到响应。

6）执行中断服务程序。这是中断请求的目的。

7）关中断。保证在恢复现场和屏蔽字时不被中断。

8）恢复现场和屏蔽字。将现场和屏蔽字恢复到原来的状态。

9）开中断、中断返回。中断服务程序的最后一条指令通常是一条中断返回指令，使其返回到原程序的断点处，以便继续执行原程序。

其中，1_{3步是在CPU进入中断周期后，由硬件自动（中断隐指令）完成的;4}9步由中断服务程序完成。恢复现场是指在中断返回前，必须将寄存器的内容恢复到中断处理前的状态，这部分工作由中断服务程序完成。中断返回由中断服务程序的最后一条中断返回指令完成。

3. 常见中断和异常

常见异常:

• 算数溢出
• 除零
• 取数奇偶校验错
• trap指令(system call)
• 硬件改变cpu执行流程
• 地址越界
• 页错误/故障
• 保护性异常(写仅读内存)
• 断点指令

常见中断:

• I/O中断
• 时钟中断
• 硬件故障

二、C/C++软件异常的常见原因分析与总结

前面讲的是宽泛的在操作系统中的中断和异常。下面我们来聊聊编程语言方面的异常。

已剪辑自: https://blog.csdn.net/chenlycly/article/details/124996473

在C++软件开发和维护的过程中，会遇到各式各样的软件异常，这些问题的分析和排查可能会消耗大量的时间和精力，会给软件研发流程的顺利推进带来不利的影响。本文根据近几年排查C++软件异常的实践经历与实战经验，详细地总结出引发C++软件异常的常见原因，给大家提供一些借鉴和参考，以帮助大家快速地定位问题。

1、概述

​ 作为一名经验丰富的C++软件研发人员，除了要有良好的代码编写与设计能力，还要有很强的代码调试能力和异常分析能力。而这些能力的培养不是一撮而就的，是通过大量的项目实践锻炼出来的。本文要讲述的内容不仅适用于刚入门的C++开发新人，也适用于有多年工作经验的C++开发人员。

​ 本文所讲的C++软件异常，是广义上的C++软件运行异常，包括软件运行时逻辑上的异常以及引发软件卡死或崩溃的异常。引发C++软件异常的常见原因有变量未初始化、内存越界、内存访问违例、Stack Overflow线程栈溢出、空指针与野指针、死循环、死锁、内存泄露、GDI对象泄露、函数调用约定不一致导致的栈不平衡等，下面将对这些原因及场景进行详细地阐述。

​ 希望大家在了解本文的内容之后，既能在编写代码时提前感知潜在的问题，也能在出问题之后多一些排查问题的思路与手段。

​ 此外，本文主要以PC端的Windows平台下的C++开发为例进行讲解，不同平台及不同语言在多个方面是相通的，也具有一定的参考价值。

2、引发软件异常的常见原因

​ 下面就来详细地讲述一下引起软件异常的常见原因及相关场景。

2.1、变量未初始化

​ 这可能是许多人容易忽略的问题。如果在定义变量时没有对变量进行初始化，在Debug下某些编译器会自动对变量自动进行初始化，但在Release下编译器不会对变量初始化，此时变量的值则是分配到内存时内存中的随机值。

​ 对于微软C++编译器，在Debug下，未初始化的栈内存会被编译器初始化为0xCCCCCCCC，未初始化的堆内存会被编译器初始化为0xDDDDDDDD，这些特殊的异常值说明如下：

​ 在调试代码时，如果遇到0xCCCCCCCC、0xDDDDDDDD异常值时，可能是变量未初始化，如果访问这些变量，则会报如下的内存访问违例错误：

如果遇到0xFEEEFEEE异常值时，可能是堆内存被释放了，如果继续将其当做有效的内存地址去访问内存，则会报如下的内存访问违例错误：

​ 如果代码中使用了没有初始化的变量，可能会导致Debug和Release下运行行为的不一致（因为Debug下编译器会自动初始化，Release下未初始化的变量的值是随机值），也可能会导致不同版本操作系统上运行行为的不一致（不同版本操作系统的内存管理机制是有差异的，比如win7和win10系统）。

​ 具体地说，代码中使用了未初始化的变量，可能会导致代码逻辑出异常，可能会导致代码产生崩溃。比如在if条件语句中使用了未初始化的变量，会直接影响程序的走向。比如访问了一个没有初始化的C++对象指针，以该指针中存放的值作为一个C++地址去访问该对象的数据成员，可能会导致内存访问违例，引发程序崩溃。再比如使用了一个未初始化的函数指针（比如存放上层设置下来的回调函数地址的函数指针），在通过该函数指针去调用函数时会是致命的，会导致程序“跑飞”了，导致程序出现胡乱的崩溃。为什么会导致程序跑飞了呢？是因为函数指针没有初始化就去访问，函数指针的值就是个随机值，根本不是一个有效的函数地址，把这个无效值作为函数地址去call，会导致不可预料的结果，可能导致程序出现胡乱的崩溃。

​ 可能有人会说，只要控制好现有的代码，就能保证不会访问未初始化的变量，不一定非要一上来就将变量初始化。即便是这样，也是不可取的，因为代码后面可能会交由其他人维护，每个人编写代码的水平是有差异的，你这里可以保证没问题，别人那边可能就会出问题。

2.2、死循环

​ 死循环一般会引发CPU高占用率，一般不会导致软件崩溃。一旦发现进程占用的CPU过高，可能就是死循环触发的，当然也有可能是新开线程的线程函数中没有添加sleep导致的（线程中不能一直在处理事务，要适当的“休息休息”）。

​ 死循环一般是for循环或while循环的循环控制条件出了问题，可能是循环控制条件写错了（比如编写代码时的手误，比如将小于号写成了等于号，导致循环条件一直成立，循环一直退不出来），也可能是循环控制条件中变量出现了异常大的值（这个值可能是服务器返回的异常值，应该要添加值的合理性判断）。这两类问题我们在联调时都遇到过。

​ 另外，还有一种情况是消息上触发的函数调用上的死循环。比如调用一个底层的接口，收到底层回应消息后，又调用了该底层接口，又收到底层的这个消息，循环往复地执行同样的函数调用，导致了死循环的发生。这样的例子，我们遇到过不止一次了。

​ 再比如在窗口消息WM_MESSAGE1的处理函数A中调用了B函数，B函数又调用了C函数，C函数中又调用SendMessage发出了WM_MESSAGE1，由于SendMessage是直接把消息发给窗口处理过程，等消息被处理完后才会返回，相当于代码是同步执行的，所以又进入了A函数中，这样就形成了消息触发的函数调用的死循环，我们在项目中曾经遇到过一次。

​ **死循环会导致所在线程的卡顿或堵塞，**如果发生在UI线程中，UI界面会出现点击没反应或者反应很慢的情况。对于Windows程序，可以使用Windbg或者Process Explorer去定位死循环所在线程及函数。

Windbg和Process Explorer是排查死循环和CPU高占用问题的利器，都可以查看到进程中所有线程的CPU占用情况，可以进一步查看CPU占用高的线程的函数调用堆栈。相比较而言，Process Explorer要更易操作一点，但就调试功能而言，还是Windbg要强大很多。哪些场景下使用哪种工具，视个人喜好及问题的具体情况而定吧。

​ 另外，这两个工具是需要pdb符号库文件的，因为要显示详细的函数调用堆栈信息（显示具体的函数名）是需要pdb符号库的（符号库中有函数及变量的详细信息）。对于windbg，需要将pdb文件的路径设置到windbg中。对于Process Explorer，只需要将pdb放置在目标exe的同级目录中，Process Exploer回到exe程序所在的目录 中去自动搜索并加载pdb文件的。

​ 关于排查CPU占用高的案例，可以参见文章：

2.3、内存越界

​ **内存越界是指操作某个变量内存时，超过了该变量的内存范围，越界到该变量内存后面的内存上了。**内存越界会篡改越界部分的内存中的内容，但内存越界不一定会导致崩溃，越界的内存区域可能是其他变量的内存区域，所以可能会篡改了其他变量的值。其他变量的值被篡改了，可能会导致软件业务出现问题，可能导致代码的运行控制逻辑出异常。

​ 内存越界包含栈内存越界、堆内存越界以及全局内存越界，这些类型的内存越界，我们之前都遇到过。

1）函数的局部变量是栈上分配内存的，对栈内存的越界称之为栈内存越界；

2）通过new和malloc等动态申请内存的，都是在堆上分配的，对堆内存的越界称之为堆内存越界。

3）全局变量和static静态变量都在全局内存上分配内存的，对全局内存的越界称之为全局内存越界。

对于程序内存分区，可参见文章：

实例详解C++程序的五大内存分区https://blog.csdn.net/chenlycly/article/details/120958761 对于栈内存越界，有可能越界到当前函数的其他局部变量上，另外在函数调用时，主调函数的返回地址、主调函数的ebp栈基址、用于esp校验的cookie值等都存在栈上的，有可能会越界到这些内存区域上，如果内存越界将这些内存破坏掉了，则会引起比较致命的错误。比如篡改了主调函数的返回地址，那么等被调函数返回时，要执行主调函数返回地址处的汇编代码，但这个返回地址被篡改了，是有问题的，所以程序就“跑飞”了，会产生莫名其妙的崩溃。主调函数的ebp栈基址是被用来回溯函数调用堆栈的，如果主调函数的栈基址被破坏，则会导致崩溃时无法回溯出函数调用堆栈，即出现崩溃时看不到有效的函数调用堆栈了。

就问题排查的难度而言，堆内存越界和全局内存越界比较难查，栈内存越界排查起来要容易很多。

​ 内存越界常见的表现形式有数组越界，操作指针指向的buffer越界等。一般都是对这些内存操作时，超过了内存的范围，主要是向后越界，可能是通过数组下标操作数组或buffer的内存，下标超过了申请内存的最大长度。

​ 以前我们遇到一种向前越界的情况，我们使用数组下标操作一段buffer内存，结果出现了下标为-1的情况，比如szBuf[-1]，这样就越界到szBuf buffer的前面去了，当时报了如下的错误：

​ 其中有一种情形下的越界（被调用函数越界越到主调函数的栈内存上），很具有隐蔽性，排查起来比较困难。比如A库依赖B库，B库定义了结构体Struct1，A库调用了B库的GetData接口， GetData接口是Struct1结构体作为参数的（传入的结构体对象引用或地址），GetData函数内部进行了数据的memcpy操作。因为库发布的问题，导致两个库版本不一致，假设A库是老版本，B库是新版本。新版本B库中在Struct1结构体中新增了字段（使用了新版本的结构体），但是A库中使用的还是老的结构体，这样在调用GetData传入结构体地址或引用，由于GetData中进行了memcpy操作导致内存越界：

// 1、A库中的代码：



Struct1 st1； // A库使用的是老版本的结构体，



GetData(&st1);



 



// 2、B库提供的GetData接口，传入的参数是结构体引用



void GetData( out Struct1& st )



{



    // 假设B库中定义的是一个全局变量g_st，即：Struct1 g_st，该变量存的是B库中的信息



    // 把全局变量g_st中的信息拷贝到st中，传出去（参数st是传出参数）    



    memcpy(&st, &g_st, sizeof(st))；



}

​ 因为B库在编译时使用了新的Struct1结构体（结构体末尾新增了一个成员字段），所以memcpy中的sizeof(st)是新的结构体字段，所以memcpy执行内存拷贝时的内存操作长度是新结构体的长度。但Getdata传入的是引用，所以memcpy的目标内存是在A模块的主调函数的栈内存上，而A模块中的主调函数传入的结构体对象用的是老的结构体（没有新增字段），所以GetData中产生的内存越界直接越界到位于A模块中的主调函数的栈内存上了。可能篡改了主调函数中其他栈变量的内存或者其他信息，可能会导致代码出现unexpected不可预期、不可解释的异常运行行为。这样的问题我们已经遇到过多次了。这类问题比较有隐蔽性，如果没有经验，排查起来会很困难

对于内存越界，我们可以通过添加多行打印日志、分块注释代码、添加数据断点（Visual Studio中支持数据断点）等手段进行定位。

2.4、内存泄漏

​ 内存泄漏是指程序中通过new/malloc动态申请的堆内存在使用完后没有释放，长时间频繁执行这些没有释放堆内存的代码，会导致程序的内存会逐渐被消耗，程序运行会变慢，直到内存被耗尽（Out of memory），程序闪退。程序闪退时，系统会弹出如下的Out of Memory的报错提示框：

如何才能察觉出程序有内存泄漏呢？其实很简单，让程序持续运行，然后查看任务管理器中程序进程使用的内存变化情况：

如果进程占用的内存一直不不断上涨且不回落，则说明进程中可能存在内存泄漏。

​ **那内存泄漏该如何排查呢？**在Linux系统中，有个强大的内存调试和监测工具Valgrind，该工具排查内存泄漏很好用，但该工具只支持Linux系统，没有Windows版本。目前Windows平台上很多内存泄露检测工具都比较陈旧、不再更新了，不再支持VS2015及以上版本编译出来的程序了。之前尝试使用腾讯的tMemMonitor内存泄露检测工具 ，但很多场景下的内存泄露，该工具都检测不出来。Windows平台下只能使用Windbg工具了，该工具监测内存泄漏的步骤稍显麻烦，可以参见之前写过的一篇文章：

2.5、空指针与野指针

​ 空指针和野指针是使用指针时两类很常见的错误，访问空指针和野指针都会导致内存访问违例，导致程序崩溃。

​ 所谓空指针是指一个指针变量的值为空，如果把该指针变量的值（值为0）作为地址去访问其指向的数据类型，就会引发问题。

​ 对于Windows系统，访问空指针会之所以会产生崩溃，是因为访问了Windows系统预留的64KB禁止访问的空指针内存区（即0-64KB这个区间的小地址内存区域），这是Windows系统故意预留的一块小地址内存区域，是为了方便程序员定位问题使用的。一旦访问到该内存区就会触发内存访问违例，系统就会强制将进程强制结束掉。

​ 关于64KB禁止访问的小地址内存区域，在《Windows核心编程》一书中内存管理的章节，有专门的描述，相关截图如下所示：

​ 比如一个C++指针变量值为空（NULL对应的值为0），如果通过该指针去访问其指向的类对象的数据成员，就会访问到64KB的小地址内存区，就会触发异常。因为会将指针变量中的NULL值作为C++对象的首地址，通过类数据成员的内存分布，C++类对象的数据成员的内存地址等于类对象的首地址加上一个offset偏移地址，这样该C++类对象的数据成员的内存地址比较小（小于64KB），要读该数据成员变量的值，就是对其内存地址进行寻址（从内存中读取内存中存放的内容），这样就访问了很小的内存地址，所以触发了内存访问违例。

​ 所谓野指针，是指该指针指向的内存（指针变量中存放的值，就是其指向的内存的地址）已经被释放了，但还去访问该指针指向的内存，一般会导致内存访问违例，导致软件崩溃。还有一种情形是同一段堆内存被delete或free了两次，也会触发崩溃。

2.6、内存访问违例

​ 前面已经讲了内存越界，内存越界肯能会导致内存访违例，但内存访问违例，不仅仅是内存越界导致的，所以这个地方要单独捻出来单独说一下。

​ 内存访问违例包含读内存违例和写内存违例。比如上面讲到的Windows下的小内存地址（64KB内存区域）是禁止访问的，一旦访问就会触发内存访问违例，系统会强制将进程终止掉。再比如上面讲的内存越界，也会触发内存访问违例。

​ 再比如系统出于安全考虑，用户态的模块是禁止访问内核态地址的，对于32位Windows程序，系统会分配4GB的虚拟地址空间，一般用户态和内核态各占2GB，用户态的内存地址是小于2GB的，如果我们通过一些分析软件发现发生崩溃的那条汇编指令中访问的内存地址大于2GB，则肯定是禁止访问内核态地址触发的内存访问违例，肯定是代码中把地址搞错了，访问了不该访问的地址。

还有一点需要说明一下，即使程序访问了不属于自己的地址，比如内存越界，不一定会触发内存访问违例，程序不一定会崩溃。程序访问了不属于当前代码块的内存地址，系统允许你访问（读数据或写数据），你就可以访问不会有内存访问违例发生；系统不允许你访问，就会触发内存访问违例，就会引发崩溃。

2.7、栈内存被当成堆内存去释放

​ 在栈上分配内存的C++类对象，是不能用delete去释放内存的，delete释放的是堆内存，否则会导致异常崩溃。

​ 之前在使用一个框架库导出类ClassA（假设类名叫ClassA），在框架库内部的框架中会自动去delete这个类对象。但我们是在一个函数中使用该类定义一个局部变量（类对象），即：

void Func()



{



    ClassA clsA；



 



    // ......



}

该类对象在栈上分配内存的，是不能用delete去释放的，应该调用接口给该对象设置不需要框架自动销毁。对于栈上分配内存的局部变量clsA，在函数退出时其占用的栈内存会自动释放。

2.8、线程栈溢出

单个线程的栈空间是有限的，比如Windows线程的默认栈空间大小是1MB，当然我们创建线程时也可以指定线程栈的大小，但一般不宜过大。

​ 线程的栈空间是用来干嘛的呢？**某个时刻某个线程实际使用的栈空间，等于当前线程函数调用堆栈中所有函数占用的栈空间总和。**函数中的局部变量是在所在线程的栈内存上分配的，函数调用的参数也是通过栈内存传递（参数值入栈）给被调用函数的，这两点就是函数占用栈内存的主要对象。

​ 一旦当前线程的调用堆栈中占用的总的栈空间超过当前线程的栈空间上限，就会产生stack overflow线程栈溢出的异常，如下所示：

导致程序崩溃。

​ 从以往排查这类问题的经验来看，导致线程栈溢出的原因主要有以下几种：

1）函数的递归调用层次过深，导致函数中占用的栈空间一直未被释放。对于递归调用，只有最底层次的函数调用返回后，上面层次的函数才会逐一返回，每个层次的函数占用的栈空间才会释放。如果函数调用一直还没走到最底下的那一层，递归调用中的所有函数的栈空间一直不会释放，线程所在线程的栈空间会被占用的越来越多。解决办法是减小递归调用的层次，或者修改变量的存储类型。

2）函数定义局部变量的结构体定义比较大（结构体比较庞大，包含了很多字段或者嵌套了很多其他的结构体），超过了当前线程的栈空间的上限。解决办法是，结构体变量不要定义成函数的局部变量，选择new或malloc去申请内存，即变量在堆上申请内存。

3）因为某些机制的存在，导致两个函数不断相互调用，陷入函数的死循环调用。导致函数占用的栈内存始终没有机会释放，导致所在线程的栈空间被消耗完了，达到了上限。解决办法是，掐断这种死循环调用机制。

4）switch语句中的case分支过多。可能这些case分支是用来处理服务器给过来的多个消息，每个case分支对应一个消息处理分支，我们会在case分支中定义生命周期在此case分支中的局部变量。**虽然代码执行到case分支中这些变量才有“生命”，但其实这些变量已经在所在函数入口处就分配好栈内存了。**可以编写C++测试代码进入调试状态查看一下汇编代码，就能看出来的，这点我特别验证过！

​ 上述四种类型的栈溢出问题，我们在项目中都遇到过，有的甚至多次遇到过。

2.9、函数调用约定不一致导致栈不平衡

​ C++中常用的调用约定有__cdecl C调用、__stdcall标准调用、__fastcall快速调用。其中，__cdecl是C/C++默认的调用方式，C/C++运行时库中的函数都是__cdecl调用。__stdcall标准调用是Windows系统提供的系统API函数的调用约定。

​ 函数的调用约定不仅决定着函数多个参数压入栈中的先后顺序，还决定了应该由谁来释放主调函数给被调函数传递的参数所占用的栈空间（是主调函数释放参数占用的栈空间，还是被调函数去释放参数占用的栈空间）。函数调用时栈分布如下：

对于由谁来释放栈空间，以常用的__stdcall标准调用约定和__cdecl调用约定为例，如果被调用函数是__stdcall标准约定，则由被调函数去释放传给被调函数的参数占用的栈空间。如果被调函数是__cdecl调用，则由主调函数去释放参数占用的栈空间。

​ 关于谁来负责释放参数占用的栈空间，大家很容易混淆，给大家一个容易记住的办法。比如我们经常用到的C函数printf：

该函数支持多个可变参数的格式化，设定的是C调用约定，因为被调函数是无法知道传入了哪些参数，只有主调函数才知道传入了哪些参数，才知道传入参数占用的栈内存的大小，所以只能是主调函数去释放参数占用的栈内存。

​ 函数调用约定引发的栈不平衡问题在设置回调函数时比较常见，特别是跨语言设置回调函数时。因为调用约定的不一致，可能会导致参数栈空间多释放了一次，会直接影响主调函数的ebp栈基址出错，导致主调函数中的内存地址错乱出现异常或崩溃。比如C#程序调用C++实现的SDK，因为C++语言中默认使用__cdecl C调用约定，C#默认使用__stdcall标准调用，如果回调函数没有显式地指明调用约定，在实际使用时就会出问题。

​ 在Debug下，Visual Studio默认开启了**/RTC（Run-Time Check）运行时检测**，如下：

其中/RTCsu选项的微软官方说明如下：

/RTC编译选项在函数退出时会监测栈是否平衡，一旦检测到栈不平衡，一般都会弹出如下的提示：

​ 默认情况下，/RTC编译选项只在Debug下是开启的，Release下该选项是关闭的。有的模块为了方便排查问题，在Release版本中开启了该编译选项。开启该选项后，在代码编译时会向代码添加很多额外的跟踪代码，会对程序的执行效率产生一定的影响。

2.10、库与库之间不匹配

​ 因为一些原因，导致dll库与dll库之间的版本不一致或不匹配，从而导致程序运行异常或崩溃。

​ 比如底层的库只发布了Debug版本的库，忘记发布Release版本，导致Debug版本库与Release库混用，因为Debug与Release下的内存管理机制的不同会导致崩溃。Debug下申请内存时会额外分配一些用于存放调试信息的内存，而Release下是没有的。

​ 再比如，底层库的API头文件发生了改动（比如结构体中新增或删减了若干字段），但只发布了库文件，忘记发布头文件，导致使用该底层库的上层库使用的还是老版本的头文件。即底层库是用新的头文件编译的，而上层库使用的是老版本头文件编译的，用到改动的结构体时在内存上就会有问题，上面的有个小节就提到这样的问题。

​ 还比如，我们修改了头文件，但发布时有若干关联的库没有编译或者编译失败了，导致程序安装包中使用的还是之前的老版本的库，这样也会导致库与库之间的不匹配。

​ 一般这类库的不匹配会触发内存上的问题，会让程序出现异常或崩溃，比如Debug下弹出如下的提示框：

处理这类问题的办法是，查看svn或者git上的库修改或发布记录，可能要重新发布库，也可能需要将相关的模块重新编译一下。

2.11、死锁

​ 死锁一般发生在多线程同步的时候，我们在不同线程访问共享资源时加锁做同步，常见的锁有关键代码段、事件对象、信号量、互斥量等。对于死锁的场景，比如线程1占用了锁A，在等待获取锁B，而线程2占用了锁B，在等待获取锁A，两个线程各不相让，在没有获取到自己要获取的锁之前，都不会释放另一个锁，这样就导致了死锁。我们需要做好多个线程间协调，避免死锁问题的出现。很多时候我们能够根据现象及相关的打印日志，初步估计出可能发生死锁的地方。

​ 如果UI线程出现堵塞卡死，或者是底层业务模块出现拥堵，业务出现异常，可能就是死锁引起的。可以将windbg挂在到目标进程上，使用~*kn命令查看所有线程的函数调用堆栈，确定发生死锁的是哪些线程，发生死锁的线程一般都会停留在WaitForSingleObject这个函数的调用或者类似函数的调用上，比如这样的截图：

如图所示，当前线程卡在了WaitForSingleObject的函数调用上。通过函数调用堆栈，可以确定是调用了哪个函数触发的。

​ 对于使用临界区（关键代码段）的死锁，使用Windbg排查比较容易分析，因为临界区是用户态的对象，我们只需要使用为Windbg进行用户态的调试即可。如果是信号量等其他的锁，则要使用Windbg进行内核态的调试，内核态的调试则要复杂很多。

​ 此外，可以使用《Windows核心编程》一书中第9章讲到的LockCop工具（有源码）来检测一下，该工具是调用系统WCT （Wait Chain Traversal，等待链遍历）API函数GetThreadWaitChain来判断目标线程是否发生了死锁，但是只能监测关键代码段、互斥量等引发的死锁，如下所示：

所以在使用LockCop工具应该注意：

1）该工具因为调用的API是Vista以上系统才提供的，所以不支持XP系统。
2）该工具只能检测临界区死锁和互斥量死锁，事件、信号量等引发的死锁是没法监测到的。
3）该工具检测不到WaitForMultipleObjects引发的死锁。

2.12、堆内存被破坏

​ 系统在给堆内存申请者分配堆内存时，会把分配给用户使用的堆内存的首地址返回给用户，用户可以在这段堆内存上进行读写操作。实际上，系统在分配堆内存时会在给用户使用的内存区域头部前面加一段头部内存，在给用户使用的内存区域的尾部加一段尾部内存，如下所示：

​ 这里额外的头部内存块和尾部内存块是用来存放给用户使用的堆内存的信息的，系统正是通过这些头部和尾部信息来管理一块一块堆内存的。这个地方做了简化的说明，实际上操作系统用来管理堆内存的数据结构要复杂很多。

​ 我们此处讲的堆内存被破坏是指这些存放堆内存信息的头部内存区域或者尾部内存区域被篡改了，一般是被内存越界篡改的，被篡改后可能会导致两个问题：

1）程序中使用new或malloc申请新的内存块时，会因为有堆内存块信息被破坏，导致分配堆内存时出异常。

2）当我们使用delete或free去释放被破坏的堆内存时，因为堆内存信息被破坏，导致释放堆内存时出异常。

所以，当堆内存被破坏后，程序可能会出现“胡乱”崩溃的问题，一会崩溃在这个dll库中，一会崩溃在那个dll中；或者一会崩溃在new或malloc时，一会崩溃delete或free时。

​ 堆内存被破坏导致的异常，比栈内存被破坏要难查的，也没有什么太好的办法。一般可以通过注释代码、注释模块去缩小排查的范围，也可以通过历史版本比对法看看是从哪天开始问题的，通过svn查看出问题前一天修改了什么代码，然后对这些代码进行针对性排查。

2.13、执行new操作时抛出了异常

​ 当我们执行如下的代码：

char* p = new char[10240];

去申请一段内存时，很多人以为当内存申请失败时new操作会返回NULL，实际运行时并不是这样，new内部会抛出一个bad_alloc异常。

​ new操作申请堆内存失败可能是以下几个原因引起的：

1）申请的内存过大，进程中没有这么大内存可用了

​ 可能受一些异常数据的影响，申请了很大尺寸的内存。比如前段时间排查一个崩溃问题，当时因为数据有异常，一次性申请了999999994*2 = 762MB的堆内存，进程中没有这么大可用的堆内存了，所以申请失败了，new操作抛出了一个异常，而程序没有对异常处理，直接导致程序崩溃了。

2）用户态的内存已经达到了上限，申请不到内存了

​ 有可能是虚拟内存占用太多，也有可能代码中有内存泄露，导致用户态的内存被消耗完了。对于一个32程序，一个进程分配了4GB的虚拟地址空间，而用户态和内核态内存各占一半，即用户态的内存只有2GB，如果程序占用的虚拟内存比较大，比如接近2GB的用户虚拟内存了，在申请大的内存就会申请失败了。或者程序中有内存泄露，快要把用户态的2GB的虚拟内存给占用完了，在申请内存可能会申请失败的。

3）进程中的内存碎片过多

​ 如果进程中在大量的new和delete，产生了大量的小块内存碎片，可用的内存大多是一小块一小块的小内存块，而要申请的是一块长度很长的内存，因为到处是内存碎片，没有这么一大块连续的可用内存，可能就会导致内存申请失败的。

4）发生堆内存越界，导致堆内存被破坏，导致new操作产生异常（此时new不会返回NULL，会抛出异常）。

​ 我们可以在出问题的地方，对该处的new添加一个保护（但不可能对代码中所有new的地方都加这样的保护），我们通过添加try…catch去捕获new抛出的异常，并将异常码打印出来，如下所示：（下面的代码在循环申请内存，直到内存申请失败为止，主要用来测试用）

#include <iostream>



using namespace std;



 



int main(){



    char *p;



    int i = 0;



    try



    {



        do{



            p = new char[10*1024*1024];



            i++;



            



            Sleep(5);



        }



        while(p);



    }



    catch(const std::exception& e)



    {



        std::cout << e.what() << "\n"



                    << "分配了" << i*10 << "M" << std::endl;



 



    }



    



    return 0;   



}

​ 还有一种方式，在new时传如一个std::nothrow参数，让new在申请不到内存时不要抛出异常，直接返回为NULL，这样我们就可以通过返回的地址是否为NULL（空），判断是否是内存申请失败了，示例代码如下：

#include <iostream>



 



int main(){



    char *p = NULL;



    int i = 0;



    do{



        p = new(std::nothrow) char[10*1024*1024]; // 每次申请10MB



        i++;



        



        Sleep(5);



    }



    while(p);



 



    if(NULL == p){



        std::cout << "分配了 " << (i-1)*10 << " M内存"         //分配了 1890 Mn内存第 1891 次内存分配失败           



                  << "第 " << i << " 次内存分配失败";



 



    }



    return 0;



}

2.14、执行delete操作时发生了异常

​ 如果对一段已经释放的堆内存再执行一次delete操作，即对同一段堆内存delete两次，第二次delete时会引发异常崩溃的。

​ 如果之前申请的堆内存在使用的过程中被破坏了，然后在delete时可能就会触发异常崩溃。我们之前就遇到过一个案例，我们申请了一段堆内存，通过数组下标szTags[nCount-1]去处理这段堆内存，结果程序在测试时崩溃了，弹出了如下的错误：

使用windbg查看dump文件，发现程序就崩溃在delete []szTags的这一行代码上。这里不存在对同一段堆内存同时delete两次的问题，以前很少遇到过delete时会产生异常的。

​ 于是通过和测试同事讨论，找到必现的规律，然后在Debug下对代码调试，发现在某种比较罕见的场景下，nCount会等于0，从而导致代码中对szTags[-1]进行赋值操作，而szTags[0]开始的堆内存块才是用户可以操作的：

**所以****szTags[-1]****就越界到堆内存的头信息内存区了，篡改了堆内存头信息，导致系统在管理这个被破坏的内存出问题了，**所以在delete这个堆内存时产生了异常。此处只是大概知道是这个原因，至于更具体的原因就比较复杂了，要研究Windows内存管理的实现细节才能搞清楚的。

2.15、GDI对象泄漏

​ GDI对象是Windows系统中的绘图操作中的概念。所谓GDI对象泄漏是指绘制窗口或绘图时，创建的GDI对象在绘制完成后没有释放，导致GDI资源泄漏，这点和内存泄漏是比较相似的。我们可以通过查看任务管理器就可以看到目标进程的GDI占用情况：

默认情况下，资源管理器中是不显示GDI对象列的，可以右键列表标题栏，在右键菜单中点击“选择列”，勾选“GDI对象”，即可查看到。

​ 当程序中有GDI对象泄露时，程序长时间运行，进程中的GDI对象会持续的增长，可以在任务管理器中实时地观测目标进程中的GDI对象变化。**如果进程的GDI对象接近或达到1万个，就会导致GDI绘图函数调用出现异常，**出现窗口绘制不出来等问题，紧接着程序就会出现崩溃。相信很多Windows老程序员可能都遇到过类似的问题。下面就是某个进程的GDI总数接近1万个的截图：

Windows系统中，进程中的GDI对象总数不能超过10000个。当进程的GDI对象总数接近或超过10000个时就会导致GDI绘图出现异常，API函数调用返回失败，甚至出现闪退崩溃。

​ 除了GDI泄漏会导致进程的GDI总数达到系统上限，打开程序的多个窗口可能也会导致这个问题，比如之前我们用MFC做UI界面时，每个控件都是一个窗口，每个窗口都包含若干个GDI对象，这样导致一个聊天窗口就占用了200多个GDI对象。这样在做极限测试时，同时打开了好几十个聊天窗口，就出现了GDI对象达到或接近上万个的问题。这也是当时我们要将MFC界面库换成开源的duilib界面库的原因之一。

在duilib UI框架中，窗口中的dui控件都是绘图绘制出来的，控件本身并不是窗口，所以dui窗口相对MFC窗口，占用的GDI对象可能要少很多。

​ 对于GDI对象泄露问题，可以使用GDIView工具来排查。GDIView可以实时显示进程的多个GDI对象个数情况，比如Bitmap位图对象、Brush画刷对象、Pen笔对象、Font字体对象、Region区域对象、DC对象以及GDI总数等，如下所示：

所以通过GDIView就能实时查看到目标进程中的GDI对象的占用及增长情况，就能确定到底哪种GDI对象数目在持续的增长，就能确定是哪个GDI对象有泄漏，这样就能有针对性地去排查相关代码了。在我们的项目中，我们已多次使用GDIView工具去排查GDI对象泄露的问题。

​ 比如有次开源组的同事在webrtc库添加了一段代码导致了GDI对象泄漏，使用GDIView工具查看，我们软件进程的DC对象一直在不断的增长，之前的版本是没有这个问题的。最近只有开源组改过代码，所以和开源组沟通了一下，起初同事觉得他们写的代码应该没有问题，应该不会导致GDI对象泄漏。于是找他们要来了他们最近添加的代码，如下所示：

#if defined (WEBRTC_WIN)



    //修正程序开启DWM导致的鼠标位置问题



    int desktop_horzers = GetDeviceCaps( GetDC(nullptr) DESKTOPHORZRES);



    int horzers = GetDeviceCaps(GetDC(nullptr),HORZRES);



    float scale_rate=(float)desktop_horzers/(float)horzers;



    relative_position.set( relative_ position.x()*scale_rate, 



        relative_ position.y()*scale_rate );



#endif

可能他们很少写UI程序的原因，对这个问题不太敏感，我们拿到后一眼就看出了问题，在调用GetDC获取DC对象之后，应该调用ReleaseDC将DC对象释放掉，所以上述代码有DC对象泄漏的问题。

2.16、对C++类或者包含C++类成员的结构体进行memset操作，破坏了C++类的内部内存结构

​ 我们通常在使用结构体时，会对结构体对象进行memset操作，以完成结构体对象的初始化，如下：

Struct1  st;



memset( &st, 0, sizeof(st) );

但禁止对类对象进行memset操作的，原因是有很多的，比如C++类中包含有虚函数，编译时会默认添加一个虚函数表指针成员变量，该指针指向虚函数表的首地址，如果对类对象（整个内存）进行memset操作，会将虚函数指针的值也置为0的，这是致命的！因为调用虚函数时需要到虚函数指针指向的虚函数表中去拿虚函数地址（代码段）地址去完成对虚函数的调用。

​ 再比如，有的C++类会添加用于维护和管理类中内存结构的额外内存块，比如STL列表类vector、list、map、queue、deque等，如果对这种类进行memset，则会破坏维护类内部内存结构的内存块，会导致不可预测的错误。对C++类的数据成员的初始化是需要放到类的构造函数中进行的。

​ 这里必须要说一种掩藏比较深的场景，这类问题我们遇到过好几次了，结构体中包含类对象也是不能进行memset操作的。比如之前同事在某个结构体定义时添加了stl列表对象成员，比如：（为了说明问题，写了一个简单的结构体）

struct PointListInfo



{



    HWND hTargetWnd;



    vector<Point> vtPointList;



};

在使用结构体PointListInfo定义结构体对象后，习惯性的对结构体对象进行memset操作，殊不知结构体中包含类对象是不能进行memset操作的。如果对PointListInfo结构体对象进行memset操作，就破坏了vector对象内部维护vector列表内存结构的内存，导致程序出现莫名其妙的崩溃。当时附加调试代码时，向vector vtPointList列表中push元素后，是能看到列表中的元素列表的，但后面在遍历该vector出现了异常，后来查下来发现是对所属的结构体对象进行违规的memset操作引起的。

​ 再比如，几年前同事在开发新功能时，遇到了一个很诡异的问题，代码是顺序执行的，按顺序执行下来肯定是没问题的，但是程序跑下来，逻辑却有明显的异常。于是我过去看了一下，发现他定义的结构体中包含有stl列表。他在使用该结构体对象之前，对结构体对象进行了memset操作，memset操作破坏了stl列表内部的内存结构，在我们读取这个列表中的数据时，stl内部抛出了异常，直接将当前函数余下的代码给跳过去了，导致本该执行到的代码没有执行，导致了程序逻辑上的异常。

2.17、程序中抛出了异常，将部分该执行的代码跳过去了

​ 程序中执行了非法的操作，抛出了异常，但程序并没有崩溃，直接将当前函数余下的代码跳过去了， 导致部分该执行的代码没有被执行到，导致后续的代码逻辑出现了问题，进而导致程序出现异常。

​ 这个问题我们遇到过几次，比如给MFC中的CTime类的构造函数传入了非法的参数值，触发CTime类接口抛出了异常。使用到的CTime的一个构造函数如下：

ATLTIME_INLINE CTime::CTime(



	_In_ int nYear,



	_In_ int nMonth,



	_In_ int nDay,



	_In_ int nHour,



	_In_ int nMin,



	_In_ int nSec,



	_In_ int nDST)



{



#pragma warning (push)



#pragma warning (disable: 4127)  // conditional expression constant



 



	ATLENSURE( nYear >= 1900 );



	ATLENSURE( nMonth >= 1 && nMonth <= 12 );



	ATLENSURE( nDay >= 1 && nDay <= 31 );



	ATLENSURE( nHour >= 0 && nHour <= 23 );



	ATLENSURE( nMin >= 0 && nMin <= 59 );



	ATLENSURE( nSec >= 0 && nSec <= 59 );



 



    // ......



}

当时传入给year参数传了0值，所以进入ATLENSURE宏中，该宏的实现如下：

#ifndef ATLENSURE



#define ATLENSURE(expr) ATLENSURE_THROW(expr, E_FAIL)



#endif // ATLENSURE



 



#ifndef ATLENSURE_THROW



#define ATLENSURE_THROW(expr, hr)          \



do {                                       \



	int __atl_condVal=!!(expr);            \



	ATLASSUME(__atl_condVal);              \



	if(!(__atl_condVal)) AtlThrow(hr);     \



} while (0)



#endif // ATLENSURE_THROW

最终调用了AtlThrow抛出了一个异常。

​ 再比如，我们把一个包含stl列表vector成员的结构体给memset了，破坏了该结构体中的vector成员的内存结构，引发了vector内部抛出了异常，就是上一小节我们说到的问题。

2.18、模块注入到程序中导致程序出现异常

​ 我们之前遇到过很多次这样的问题，输入法的库注入到我们软件的进程中，导致了我们软件出现崩溃。通过分析发现，崩溃是发生在输入法的模块中，但因为这个模块是注入到我们的进程中的，所以直接导致了我们软件的崩溃。此外，输入法注入到我的进程后还出现了软件卡顿、CPU占用不间断跳高的问题。解决办法是让用户换输入法。

​ 除了输入法，还有一些安全软件也会注入到我们的进程中，导致我们的软件出现异常，这样的问题我们也遇到过几次。比如以前我们就遇到这样一个问题，有个客户的机器上安装了多个安全防护软件（安全级别比较高），运行我们的软件一段时间后就会崩溃闪退，经远程到客户的机器上查看到任务管理器中的进程的内存在持续增长，估计是**软件中发生了内存泄露，增长到一定程度后就导致内存耗尽，发生了闪退。**最终使用windbg定位到内存泄露发生在安全软件的注入库中。它这个库是注入到我们进程中的，库内部发生内存泄漏，会表现在我们的进程中。解决办法是让安全软件开发商去排查他们开发的安全软件问题。

​ 再比如几年前遇到的一个客户问题，他们的Windows系统中安装了VPN软件，注入到我们的进程中，hook了网络通信的相关接口，以监控软件的网络数据包的收发，其中hook的recvfrom接口实现有bug，我们代码中有处调用recvfrom接口的地方传入了NULL参数（对于系统API函数recvfrom，传入NULL值是允许的），结果直接导致该注入模块产生了崩溃，进而导致了我们软件的崩溃。

​ 查看微软MSDN上对套接字API函数recvfrom的说明，函数的最后两个参数是可选的，可以不传入，直接设置NULL就可以了，如下所示：

但客户VPN软件注入模块，将系统的recvfrom函数hook成了他们实现的recvfrom函数，在实现他们自己的recvfrom函数时，直接访问了recvfrom最后的两个参数，而我们的代码在处理这两个参数时直接传入了NULL值：

这样在他们的recvfrom内部没有做空指针的判断，访问了NULL指针，触发了内存访问违例，导致VPN软件的注入模块发生崩溃，从而导致了我们整个程序的崩溃。对于这个问题，我们有临时的规避办法，我们只要传入两个有效的参数即可：

当然在对应的代码中，我们并不关心这两个参数在函数调用完成之后的返回值，不再传入两个NULL参数。

像这类出在第三方安全软件中的问题，必须要拿出足够的证据，证明问题是出在安全软件上，客户才会认可排查的结论，客户才会找第三方安全软件开发商去沟通反馈问题。

2.19、添加日志打印覆盖了lasterror的值

​ 调用Windows系统API函数之后，系统API函数都会设置LastError值，我们可以调用GetLastError接口获取LastError值，有时我们需要使用该值进行一些判断。可能在判断之前我们又加入了一行代码，这行代码中也调用了系统函数，将之前的系统函数调用产生的LastError值给覆盖了，导致判断逻辑出问题了。

​ 以几年前项目中遇到的一个问题为例，来详细地说明一下这个问题。当时在新需求开发完成后软件进入测试，测试发现我们的客户端软件始终连不上某个业务服务器，用Wireshark抓包看到客户端对服务器发起了三次握手的流程，客户端发出了SYN包，服务器收到SYN包后给出了ACK回应，但是客户端始终没给出ACK报应答，然后客户端直接将连接reset了。

​ 最开始我们怀疑是客户端所在的系统的防火墙拦截了服务器的数据包，导致客户端应用层无法收到服务器的数据包。于是将程序添加到防火墙的信任列表中，允许通过防火墙进行通信，但还是有问题。于是分别将防火墙和杀毒软件都关闭掉，但问题还是照旧。

​ 后来通过排查代码得知，建链时用的是非阻塞式套接字，发起connect之后会检测connect设置的lasterror值，结果在检查该lasterror之前，添加了一句打印：

就是这句打印引起的。打印接口中调用了系统API函数或者C函数，覆盖了调用connect时设置的lasterror，导致后续判断connect设置的lasterror值出错了：

然后客户端直接调用closesocket接口直接将套接字关闭了（从抓包上看，连接直接被reset了），结束了三次握手的流程，所以客户端始终连接不上服务器。

​ 类似的问题我们遇到不止一次了。本例中的问题出在开源的libjingle库（XMPP客户端代码）中，开源代码中做了多层函数的封装，在多个函数返回后才去判断connect设置的lasterror值，所以该问题具有很强的隐蔽性。在我们不太熟悉代码的情况下，添加了一句打印导致了这个问题。

2.20、格式化时格式化符与参数不一致

​ 在将数据格式化到字符串中时，如果格式化符与参数类型不一致，可能会引发内存访问违例，导致软件崩溃。比如一个整型的变量（保存了一个很小的整数），结果错误的对应了%s格式化符，这样格式化函数内部会把这个整型值当成一个字符串首地址去对待，会读取这个内存地址中的字符串，但是这个地址是个很小的地址，即程序访问了64KB范围内的小地址存储区，这个区域是禁止访问的，会触发内存访问违例，系统会直接将进程终止掉。

​ 几年前，我们遇到这么一个看似很奇怪的格式化时的崩溃，崩溃的那行代码如下所示：

参与格式化的两个参数是duilib中的CStdString字符串类对象，既然是字符串，上面的代码看上去好像是没问题的，但为啥运行时会产生崩溃呢？百思不得其解！

​ 后来我们才发现，CStdString字符串类中有两个数据成员，正是这两个数据成员导致的问题。CStdString类的成员如下所示：

在调用格式化函数时，待格式化的参数会通过栈传递给被调用函数，具体是将参数内存中的内容压到栈上，格式化函数内部正是通过格式化符对应的内存长度从栈上读取待格式化数据的，这里就涉及到函数调用时的栈分布的知识了。为了方便理解问题，下面给出调用格式化函数时的栈分布图示例：

​ 参照上图，本例中要参与格式化的CStdString类对象，两个数据成员都会压入到栈上，第一个参数m_pstr，压入的是字符串的首地址（正是要格式化的字符串），第二个数据成员m_szBuffer压入栈的也是内存地址中的内容，不是m_szBuffer数组的首地址，这样格式化函数会把m_szBuffer数组中的内容作为%s对应的字符串的首地址，这明显是有问题的。m_szBuffer数组中保存的是字符串各个字符的ASCII码，根本不是什么字符串的首地址。硬要作为字符串地址去解析，可能地址是不可访问的，会触发内存访问违例，导致崩溃。

2.21、同一个程序在不同系统中可能会有不同的表现

​ 当前用的最多的系统是win10，win11也开始推出来了，也有部分人用的还是win7和win8，甚至还有极少数人还在用XP，不同的系统底层的实现会有一定的差异，比如说内存管理模块，同一个程序在win7上运行可能是没问题的，但是拿到win10系统上跑可能会有问题。这个我们之前就遇到过。

​ 即便是同一个型号的系统，比如都是win10的系统，也分教育版、专业版和旗舰版等，并且不同时期的版本也可能会有一定的差异。比如最近我们还遇到过这么一个问题，在安装2015版win10系统（微软surface平板）上有CPU占用过高的情况，但在2019版的win10系统中则没有问题。

​ 几年前我们也遇到过一个很特殊的实例，测试同事无意发现一个掩藏很深的崩溃，且是必现的，在win7系统上将windbg附加到进程上后，竟然不再崩溃，但直接运行程序就有异常，这个着实有点诡异！我们将程序拿到另一台装有win8的电脑上运行，用windbg附加到进程上调试，竟然是能抓到异常信息的。这个案例也给了我们一个启示，当遇到问题时可以到不同的系统上去跑一跑，说不定有意外的收获。特别是在软件发版本之前，一定要在多个版本的系统上做测试。

​ 不同系统中程序的表现可能会有差异，同一类型的系统在不同时期的版本中也可能会有一定的差异，所以我们在测试的时候，要把程序拿到多个系统中去跑一跑，去测一测，保证程序能在多个系统上都能正常的运行！

2.22、其他

​ 除了上面讲到的这些异常，还有一些其他异常，比如除法表达式中的除0崩溃，比如表达式的计算结果过大超出了变量类型所能表示的最大值，导致变量溢出了等。

​ 除了要了解这些常见的软件异常类型，还需要掌握一些常用的软件调试技能，可以查看文章：

3、最后

​ 本文详细介绍了引发C++软件异常的常见原因，并给出了详细的讲解和相应示例说明。希望大家在了解本文的内容之后，既能在编写代码时提前感知潜在的问题，也能在出问题之后多一些排查问题的思路与手段。

​ 接下来，下一篇文章将详细介绍排查C++软件异常的常用方法与手段，敬请期待！

三、实时操作系统对中断和异常的处理

对于编制嵌入式操作系统B$P或驱动程序的工程师来说，中断或异常处理是必须要面对的工作。而应用层工程师要想在嵌入式操作系统环境下开发出高效可靠的代码，也必须要求在此方面具备足够的知识。
在这一章中，将主要介绍VxWorks的中断（Interrupt）处理，同时引入中断与异常（Exception）。的比较。中断和异常是RTOS中一类非常重要的概念，也是RTOS获取外部事件的主要手段。在此基础之上，进一步介绍Vx Works中的时钟（Clock）和定时器（Timer）使用。

1. 中断和异常的基本知识

中断和异常是一对经常被混淆的概念，因为从应用层的视角来看，中断和异常的发生都会导致CPU当前执行的指令流被打断。为了从概念上区分它们，首先必须给“异常”一个确切的定义。广义上的异常指的是这样一种事件，它打断了CPU的正常执行流程，迫使其进入到一种特权状态（Privileged Mode）去执行特定的指令。
依据触发源的不同，异常可以被分为：同步异常（Synchronous Exception）和异步异常（Asynchronous Exception）。同步异常的产生是由于内部事件的触发，而这个内部事件的出现和当前正在执行的指令密切相关，比如说除零（Division by Zero）、内存访问错误、MMU的TLB表未命中等。异步异常的产生则是由于外部事件的触发，这种事件的出现与当前正在执行的指令没有关系。一般说来，这些外部事件都与某个特定的硬件信号相关。最典型的异步异常的例子就是系统复位异常（Reset Exception），当按下复位按钮后，复位异常就会被触发。
按照这种解释，其实常说的中断，在概念上等价于异步异常，是异步异常的一个种类，只是因为中断已当作术语被广泛地使用，所以常用中断来代替异步异常。（从这个意义上讲，中断是异常的一种也是没有错的。）除复位异常等个别情况之外，通常所说的异常则特指同步异常。《Vx Works Programmer’s Guide》中沿用了这种习惯用法，如果没有特别强调，在下面的描述中都遵循这种用法。

VxWorks中断概念

当CPU接收到来自外设的中断信号，便立即停止当前正在执行的指令，保存现场，并转而执行指定的ISR（InteruptServiceRoutine中断服务程序）。在ISR执行结束后，CPU再次恢复现场，然后继续刚才被打断的工作。这一过程称之为中断处理。
操作系统中引入中断处理的最初目的，其实是为了实现并发处理，或是说为了平滑CPU与外设之间的速度差异。在绝大多数实时嵌入式系统中，这种并发处理的能力更是一个必备的特性。此外，CPU也主要通过中断来获知系统外设需要服务。
中断处理过程是软件与硬件的综合，将其称之为中断系统也并非言过其实。在这个系统中有一系列的术语：产生中断信号的事件叫做中断源（InterruptSource），中断源向韩Ddo（tsonbadnou）本中h水重DdO中断请求的过程称之为中断响应（InterruptResponse），处理中断源的程序叫做中断服务程序（ISR-InterruptServiceRoutine）。对于有多个中断源的系统，一般按照中断的重要程度、对实时性的要求等因素采用分级管理方式，而每个中断拥有的级别叫做中断优先级（InteruptPriority）。大多采用可编程中断控制器（PIC-ProgrammableInterrupt Controller）来实现优先级判别和中断源的准确定位。
中断的分类，不仅和处理器的体系结构有关，同时也和操作系统相关。经常可以听到的一些说法就是“软中断”和“硬中断”。在VxWorks当中，把信号机制（Signal）叫做“软中断”，而把硬件外设产生的中断叫做“硬中断”；而在Linux中，由于中断的实现机制的不同，软中断则是指硬中断服务程序对内核的中断，硬中断是内核（或是其他进程）对某个进程的中断。
不管是什么样的中断，基于何种处理器体系，CPU对于中断的响应和处理过程还是基本一致的。在指令执行过程中，CPU会适时扫描，查询有无中断请求。一且识别到中断发生，首先就要保存现场，然后依据中断源提供的中断向量（InterruptVector），找到ISR的入口并执行，ISR返回时恢复现场。

VxWorks异常概念

CPU的内部事件触发异常，或者更确切的说，是由于当前指令的执行导致了特定寄存器的状态被改变，使得系统进入某种错误状态（ErrorConditions）或是特殊状态（Specia】Conditions），于是CPU保存现场后转而执行指定的异常服务程序（ESR:ExceptionService Routine）
除零、数据溢出（DataOverflow）或一个非法的内存访问都会使得错误状态产生。对于特殊状态，有的处理器体系提供一些指令，使得系统强制地进入特权状态，比如说Motorola68K处理器提供的自陷（TRAP）指令。此外，另一个比较常见的方法就是跟踪异常（TraceException），这是由断点指令产生，并由Debugger代理负责处理。正是这种机制的实现，使得可以设置断点并单步跟踪代码的执行。
异常处理对于一个嵌入式系统来说是必要的，它使得指令中的错误不至于扩散到整个系统，至多只是影响当前执行的任务（Task）。此外，异常也为调试代码提供了通道。

在下面的描述当中，关于异常处理的讲解主要是针对错误状态的处理句柄（Handle）。在VxWorks中，系统会提供默认的异常处理程序，即Suspend出错的任务，并且记录现场，同时把错误状态的描述传递给tLogtask任务，然后转入新一轮的进程调度。如果需要，用户也可以对某些异常指定异常服务程序，替代系统默认的操作。

中断和异常的比较

通过上面的简单比较，可以说中断与异常的差别其根本就在于触发源的不同。此外，异常的发生是和当前正在执行的指令相关，也就是说异常是同步的，有可预测性。而中断的发生却是随机的，是不可预测的，因为它和当前正在执行的指令无关。
也正是由于这些不同，导致了它们在VxWorks中的处理方式也有所区别。在VxWorks中，异常的处理并没有涉及到任务上下文的切换，而ISR的执行却是在特定的上下文中。在默认处理中，异常发生后，任务的状态已经成为Suspend状态，而ISR结束后，要继续执行当初被打断的那个任务。
无论是否存在可编程中断控制器，处理器通常都设法为多个中断源设立优先级机制，并提供可屏蔽（Maskable）功能。而对于异常却大多没有可屏蔽机制。
其实，对于操作系统而言，无论中断或是异常，它们的处理流程都极其相似。可以简单地概括为“四步走”：保存现场、分析原因、处理中断、中断返回。

2. VxWorks中断服务

实时系统借助于中断的手段来获知外部事件，为了尽可能以最快的速度做出反应， Vx Works的中断在具体实现上有其特殊性。

VxWorkss中断基础

中断处理流程的第一步便是“保存现场”。保存被中断任务现场的目的是为了在中断处理完之后，可以正确地返回，在原有的运行环境下继续执行。通常，中断响应时硬件已经保存了PC（ProgramCounter，程序计数器）和PS（ProcessorStatus，处理器状态字）的内容，同时还有一些状态环境信息需要保存起来。对现场信息的保存方式是多样化的，常用方式有两种：
1）集中式保存：在内存中专门设置一个中断现场保存堆栈，所有中断的现场信息都统一保存在这个堆栈中。
2）分散式保存：就是在每个任务的控制块中设置一个堆栈区，一旦该任务被中断，它的中断现场信息就保存在自己的堆栈区中。
如果处理器的体系结构允许，VxWorks将使用集中式的保存方式。堆栈的定位和初始化依据指定参数在系统启动时进行配置。当然，如果一些体系结构不支持独立的中断堆栈，那么ISR就使用任务的堆栈。至于堆栈的大小，取决定于最坏情况下中断嵌套（IntemruptNested）的深度。VxWorks提供了一个函数checkStackO）来检查任务堆栈的使用情况。
中断系统的复杂，就在于它既涉及到软件，又和硬件相关。为了实现对多个中断源的分级式管理，通常使用可编程中断控制器（PIC）。虽然在不同的处理器体系中，PIC的表现形式千差万别，但是实现的主要功能却大体相同：
1）对多个中断源进行优先级排序，保证优先级最高的中断请求最先得到处理。
2）对每个中断源提供屏蔽机制，并可能提供完全屏蔽功能。
址“江事（oursonbaidnuour）水中心一回查并中心（8力向CPU指明究竞是哪个中断源触发的中断事件。

为管理多优先级中断源，在Vx Works中利用一张中断向量表（Interrupt Vector Table）
进行描述。表的结构实际为一个结构数组，每项可记录两个内容：用户中断服务程序入口和一个参数指针。系统中的每个中断源预先分配一个特定号码，称为中断号（Interrupt Number）。每个中断号对应一个中断向量（Interrupt Vector），它实际是对应中断在中断向量表中的序号或偏移。Vx Works中提供了两个专用的宏定义，用于实现在二者之间的转换：
NUM_TO_IVEC（intNum）：将一个中断号转换成中断向量。
IVEC_TO_NUM（int Vec）：将一个中断向量转换成中断号。
在某些处理器体系中，还有Interrupt Level（中断级别）的概念，尽管可以通过Interrupt Level判定中断的优先级，但是并不能简单地认为它等同于中断优先级。Interrupt Level是相对于IRQ（Interrupt Requirement）而言的。随着芯片集成度的提高，一些专用芯片将原本是外设的控制器集成到了芯片的内部，而由这些被集成的“外设”产生的中断请求被叫做Interrupt Level，而真正来自于芯片外部的设备的中断请求则是IRQ。
下面就以Motorola MPC8xx系列处理器中MPC860的中断系统为例，结合上面讲述的一些内容来介绍一下Vx Works在PowerPC体系上的中断处理过程。
MPC8xx系列处理器为面向通信应用的嵌入式设备而设计，采用双CPU的架构，由三个功能相对独立的模块构成：PowerPC Core（PowerPC内核）、SU（System Interface Unit）、CPM（Communication Processor Module），如图6-l所示。
CPM负责控制和管理系统中绝大部分通信端口设备，每个设备甚至/O端口的管脚都是独立的中断源。因此CPM本身就要管理30多个中断源。在CPM当中，主要由5个寄存器协同扮演中断控制器的角色。当CPM中的某个中断源产生中断信号，CPM中断控制器（CPM Interrupt Controller）从中断请求中选择优先级最高的送往SU中断控制器（SIU Interrupt Controller）。在SU中断控制器汇总了来自芯片内部和外部的绝大部分中断请求（NMI和Decremeter中断除外），对来自芯片内部的中断请求被配置在优先级Interrupt Level（0_{7），来自于芯片外部中断管脚的中断请求也按照优先级被配置在IRQ（0}7）。其中来自于CPM的中断请求缺省默认配置在mtemupt tLevel4.而IRQO与WatchdogTimer都是作为不可屏蔽中断请求被送往PowerPC Core. SIU中断控制器则负责从ImtemruptLevel（0_{7）和IRQ（1}7）中选择优先级最高的中断请求送往PowerPC责从的外部中断引线，因此PowerPCCore对来自于SIU的中断请求都作为外部中断（Extermal Interupt）处理。

在面向MPC8xx的VxWorks系统中（VxWorksforPowerPC），SIU的InterruptLevel（0～7）以及IRQ（0～7）都分配有相应的中断号和中断向量。不仅如此，CPM的每个中断源也有对应的中断号和中断向量。只要在VxWorks的中断向量表中占有一席之地，用户就可以为对应中断提供自己的ISR。
VxWorks允许中断嵌套。中断嵌套赋予了高优先级的中断抢占CPU的手段。这样可以使紧急的事件及早得到处理。需要注意的是，当允许中断嵌套时，堆栈的大小决定了中断嵌套的深度。

ISR的特殊限制

Vx Works对它所支持的体系结构提供有标准的中断服务程序，但只是提供必要的，并不是全部。其他中断服务程序在需要时由用户编写，VxWorks提供标准的接口进行配置安装，在对应的中断发生时，由系统自动调用。
虽然没有对ISR的代码长度做限制，但是应该尽可能在最短的时间内完成操作，以免影响实时系统对高频率突发事件的响应。另外，VxWorks的ISR必须遵循一个基本约定：不能调用可能引起阻塞的函数。举例来说，ISR不能调用semTakeO来试图获取一个信号量。，因为在此调用中，一旦发现信号量不可用，调用者会随之转入阻塞状态。此外，诸如函数malloc0和freeO这些函数在实现时也是要获取一个信号量，所以，ISR也不能调用。ISR还不能调用那些使用浮点协处理器的函数。因为在由intConnectO创建的中断驱动代码中不保存和恢复浮点寄存器。
在ISR中可以调用semGiveO来释放一个信号量，最好使用logMsg0向Console输出信息，也可以使用msgQSendNO_WAIT）来和其他task进行消息交互。表6-1中列举了ISR中可以调用的函数。

中断服务程序设置

为了缩短系统对中断的处理时间，多数情况下，VxWorks的ISR都运行在特定的上下文当中，这个上下文独立于任务的上下文。因此，中断处理不会涉及任何任务的上下文切换。VxWorks对于中断系统配置提供的API主要集中在库intLib和intArchLib表6-2列举了部分常用的函数。