C++ 常见崩溃问题分析

从事自动化测试平台开发的编程实践中，遭遇了几个程序崩溃问题，解决它们颇费了不少心思，解决过程中的曲折和彻夜的辗转反侧却历历在目，一直寻思写点东西，为这段难忘的经历留点纪念，总结惨痛的教训带来的经验，以期通过自己的经历为他人和自己带来福祉：写出更高质量的程序；

由于 C 和 C++ 这两种语言血缘非常近，文本亦对 C 编程语言有借鉴作用；

在编程实践中，遭遇到了诸如内存无效访问、无效对象、内存泄漏、堆栈溢出等很多C / C++ 程序员常见的问题，最后都是同一个结果：程序崩溃，为解决崩溃问题，过程都是非常让人难以忘怀的；

可谓吃一堑长一智，出现过几次这样的折腾后就寻思找出它们的原理和规律，把这些典型的编程错误一网打尽，经过系统性的分析和梳理，发现其内在机理大同小异，通过对错误表现和原理进行分类分析，把各种导致崩溃的错误进行归类，详细分类如下：

其它如内存分配失败、创建对象失败等都是容易理解和相对少见的错误，因为目前的系统大部分情况下内存够用；此外除0错误也是容易理解和防范；

为了更好的理解崩溃错误产生的根源，我们一起回顾一下几个概念和知识点，为后面的讨论打下基础；

由于本篇只谈程序设计，不谈软件设计，故忽略了文档开发、过程管理、软件测试、配置管理等内容，各位看官在审阅文档中的著述时若有分歧请勿忽略这个隐喻；

3.1、程序构造视图

Pascal 之父、结构化程序设计的先驱 Niklaus Wirth提出了著名的公式：算法 + 数据结构 = 程序，以简单直接的方式道出了他对软件开发的理解，简明扼要的说明了程序设计的本质；为了更加全面的暴露程序设计的本源，我们把这个公式稍加扩展：算法 + 数据结构 + 内存管理 = 程序设计，它进一步揭开了程序设计的老底：程序设计需要关注内存空间管理；

从计算机科学的发展趋势来看，Niklaus Wirth 极具远见卓识，因为现代程序设计越来越不需要关注内存空间的使用了，首先是由于科技的发展，存储器件成本越来越低，物理内存容量越来越大；其次是动态语言和以Java为代表的托管语言都具有自动内存分配和垃圾内存回收功能，用户只需要专注于人机交互、数据结构设计和业务逻辑的梳理了；

C / C++ 这类传统的静态语言也追随着这股潮流，在内存空间管理方面添加了越来越多的自动化支持，简化了内存管理，然而简单并不意味着内存管理的复杂性消失，出现崩溃问题时我们一筹莫展正是因为简单性蒙蔽了我们的思维，而崩溃的根源就是内存空间的使用不当造成的，因此对操作系统原理、内存管理、语言语义的透彻理解是我们解决崩溃问题的关键所在；

3.2、进程内存布局

在介绍详细介绍进程空间内存布局之前，我们首先看一下 Windows 的资源管理器进程的内存布局视图，如下所示：

图（一）Windows资源管理器内存分布图

图（二）Windows资源管理器内存地址空间分布图

从上图可以看出，进程内存地址空间被划分为8块（Managed Heap是另一种内存堆），并且各块内存不是聚集在一起形成连续内存块，而是按需加载使用内存；他们的详细情况如下：

由于编译器在后台做了大量的内存管理自动化工作，因此程序设计过程中主要关注的内存区域类型有：Stack、Heap、Free（Free Virtual Address Space），下面我们对这几种做一个简要介绍：

Stack 是一块固定大小的连续内存，受运行时管理，无需用户自行分配和回收；当函数调用嵌套层次非常深时会产生 Stack overflow（堆栈溢出）错误，如递归调用、循环调用、消息循环、大对象参数、大对象局部变量等都容易触发堆栈溢出；

Heap 主要用于管理小内存块，是一个内存管理单元，默认为1MB，可动态增长；每一个应用程序默认有一个 Heap，用户也可以创建自己的 Heap，new/delete, malloc/free 都是从堆中直接分配内存块；

Free（Free Virtual Address Space）即进程空间中的整个可用地址空间，它会以两种方式被使用，一种是Heap 自动分配和回收，一种是直接使用VirtualAlloc*/VirtualFree* 分配和回收；用户对它的直接使用是用于分配连续大块内存，分配和释放的速度比使用 Heap 更快；

3.3、数据结构视图

内存始终都还是内存，所不同的是我们解读内存的方式不同；从代码视野来看内存中的数据结构，它就是对一块连续内存的专有解读；对任何一个内存地址，我们可以用数据结构A视图来解读，亦可以用数据结构B视图来解读，使用正确的数据结构视图读到正确的数据，使用错误的数据结构视图我们读到错误的数据；为了简明扼要的说明这个问题，我们来个案例：

记住这一点非常重要，C / C++ 程序设计中的很多技术法门都出自这；例如基本类型转换、指针对象转换、面向对象的多态、改写只读对象等都体现为连续内存块的解读视图变化；

由于操作系统已经接管了物理内存的使用，并且提供了透明的访问机制，对内存的使用更直接体现为对操作系统提供的进程地址空间的分配和回收；

在实际的编程实践中，程序员需要把整块空间再细分为8位、16位、32位、64位、8位连续块等数据空间，这里还涉及到两个概念：字节对齐和字节序列（又名端序，有大端小端之说），透彻理解编译器的对齐规则和处理所支持的字节序列，对于正确理解内存中的数据很关键。

3.3.1、字节序列

字节序列对于网络编程的同学尤其熟悉，因为需要把数据包在本机字节序列和网络字节序列（大端序列）来回转换，部分经常使用printf和基于偏移量访问内存的同学也会遇到字节序列带来的烦恼；

字节序列简单的讲是对大于一个字节的数据在内存中如何存放的问题，比如32位整数需要使用4个字节，这个四个字节该如何放置？按照二进制位切割为四个字节吗？下面我们详细介绍一下字节序列的两种定义：

端序的内存案例：

下面我们来看一个实践中产生的和端序想关联的问题，案例来自 Vimer的程序世界

为什么会这样？有同事对该问题做了精辟的注解，为了尊重作者版权，故截图分享，请看下图：

【注】这个Bug依赖于编译器实现，可能在某些编译器上不会重现。

3.3.2、字节对齐

字节对齐涉及内存分配的问题，具体涉及到结构、联合类型、类成员数据的对齐分配，编译器根据不同的对齐规则分配不同的内存空间。

掌握对齐规则后，我们就可以在使用标量类型时、设计结构、联合、类类型时合理选择类型，既可以合理使用内存空间，又可以提高程序性能；下面我们看一个来自实践中的案例：

从上面我们可以看出，在默认对齐规则下，单个实例会浪费5个字节的内存，如果1万实例则会浪费 48 K内存，如果再加上不合理的长度定义，可能浪费更多的内存空间，在小内存空间限制的系统中，这显然是巨大的优化空间。

3.4、函数参数传递

C/C++ 的入口程序就是函数，函数需要传入参数，详细了解参数分类、传递规则、传递过程对写出正确且高效的程序起着至关重要的作用。笔者就曾因为传错了一个参数而导致程序崩溃，最后费了非常多的时间来查找原因，最后找出的原因是取址符(&)用错了，这让我下定决心彻底搞明白参数是怎么回事。

3.4.1、函数参数详解

参数分为输入参数、输入输出参数、输出参数、返回参数四种，分别适用于用于不同的场景，其作用和值得关注的细节如下：

在输入参数和返回参数添加常量修饰符const 是一个非常好的编程习惯，能显著的预防很多错误，因为我们不知道编译器自动生成的参数入栈代码和参数出栈代码的具体模样，亦不知它何时何地执行，只能最大化的防范它的风险。

参数传递顺序有从左到右传递、从右到左传递两种，由于参数也是一个表达式，关注参数的求值顺序对写出正确的程序非常关键，例如：calc (origin++, origin+inc)，如果不清楚参数表达式求值顺序就无法正确理解程序；

参数传递方式有值传递、引用传递、指针传递三种，三种参数本质上都是【值传递】，基本类型由于地址所指即为真实数据，传递时会生成真实数据的拷贝，将会消耗更多的堆栈内存，而引用传递和指针传递乃间接指向对象，传递时只是生成地址的拷贝，堆栈内存消耗比较少；我们首先对各个概念做一个简要回顾：

很多函数调用阶段的细微错误就是忽略了参数传递的细节造成的，例如参数求值顺序、值传递还是引用传递等因素，堆栈溢出有很大一部分因素是因为错误的把结构和类对象以值传递方式传给函数导致的；

3.4.2、函数参数约定

参数传递顺序和传递形式组合形成了几种不同的函数调用约定，下面我们一起回顾一下编程实践中常见的几种约定：function resize(void ** p)

【注】VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用，C++调用约定中的符号(*)需要根据参数填充；

由于函数调用清理代码由编译器自动生成，例如C/C++ 函数调用由调用函数清理堆栈，编译器会把清理代码生成在紧挨着被调用函数位置还是在函数退出前位置？对于我们来说是未知的，这里产生了潜在的未知风险；

3.4.2、函数参数能效

参数如何传递才最安全、最有效率？

Windows平台的调用栈空间是在链接时固定分配并写入二进制文件，UNIX类平台则可以通过环境变量设置，他们的默认栈初始空间情况如下：

指针传递、引用传递都是传递对象的地址，传给函数时都是把这个地址压入栈，32位平台为四个字节，64位平台为八个字节，除结构实例、类实例外的标量类型，其数据长度均固定，可以精确的计算参数所需空间；我们做个简单的计算：取平台位宽为参数空间平均长度，以平均每个函数三个参数、1000级函数调用来计算，他们的占用空间如下：

由此可以看出，标量类型、指针、引用等数据类型长度都小于等于机器字长，占用的空间小，入栈、出栈速度都是非常块的，一般情况下默认栈空间足够使用，不会出现堆栈溢出的问题；

哪些数据类型会潜在的降低程序效率呢？答案是结构类型、类类型，他们是程序低效率的潜在幕后黑手；由于标量类型、指针、引用占用的空间等都是机器字长，标量类型无论使用哪种方式传递，和指针、引用都是同样的速度；结构类型、类类型的值传递方式呢？

咱们需要了解一下结构类型、类类型的值传递过程：调用参数类的复制构造函数生成新的类型实例并入栈，复制构造函数编译器自动生成，用户亦可以自己编写一个；我们可先看一个案例：

这段代码在 Visual C++ 编译器下运行的结果如上所示，其中多次执行最后三行代码，第三个窗口表现一致，由此我们可以判断出结构、类的复制构造函数不会深度复制对象，用值传递时会丢失数据。结构、类由于包含多个成员，逐个复制会倍数于标量和指针操作，带来了速度的降低；

前面的试验探讨了值传递、指针传递、引用传递，标量类型、指针、引用传递参数长度固定，安全高效，但结构、类的值传递方式带来诸多问题，例如堆栈溢出、数据丢失、效率低下等，建议结构、类完全使用指针或者引用传递；

3.5、变量生命周期

变量声明了，是不是直接使用就万事大吉了呢？我们当然希望就是这么简单，动态语言和托管类型语言确实实施了严格初始化机制：变量只要声明就初始化为用户设置的初始值或者零值；然而 C/C++ 不是这种实施了保姆级初始化机制的语言，透彻了解 C/C++ 的初始化规则对帮助我们写出健壮的程序大有裨益；

3.5.1、变量内存分配

C / C++ 支持声明静态变量（对象）、全局变量（对象）、局部变量（对象）、静态常量等，这些变量在分配时机、内存分配位置、初始化等方面上有些细微上的差别，熟悉并掌握他们对于写出正确的程序非常有帮助，请看下表：

对象创建后的成员数据取决于构造函数及其参数，系统自动生成的构造函数是不会初始化成员变量的；

对于函数、结构实例、类实例中的变量，编译器不会自动初始化，其值是不确定的，故直接使用会导致不确定的行为，这就是实践中经常碰到的程序行为表现莫名其妙的根源所在；

对于动态分配的内存(new/delete、new[]/delete[]、malloc/free)，默认是不会置初值的，需要显式的初始化；对于结构和类型实例，new/new[]操作会自动调用构造函数初始化内存，详情请参见【对象初始化】；

【注】使用 VirtualAlloc/VirtualAllocEx 分配的虚拟内存会自动化初始化为零值；

【注】使用 HeapAlloc 分配的堆内存可以通过参数设置初始化为零值

3.5.2、变量初始化

从前面的变量初始化中得知结构实例、类实例、函数中声明的变量是不会自动初始化的，需要用户显式的初始化；值类型相对比较安全，可以声明时即初始化，这是最安全的作法；