今天开电话会议，帮助合作方排查 C++ 开发的程序崩溃的原因。

   现象是这样的：

   有一个 C++ 对象，其中有一个 vector ，里面存放了大量对象指针。这个 C++ 对象在构造完毕后，没有任何改写操作，全部是只读的。

   在某个退出环境中，C++ 对象被析构，析构函数需要调用 vector 中所有对象指针的删除方法。这时，这个长度大约为 100 多的 vector 第 95 个指针是错的。比它应该的指针位置偏移了一到三字节(多次运行现象不一)。

   整个数组只有这一个指针错误。因为这个错误，引发了程序崩溃。

   从电话中的描述，我推断：

   这不太可能是由错误的调用此 C++ 对象的方法改写 vector 的内容导致的，因为这个对象全部是读方法，并加了 const 修饰。且，这个数组保存的是对象地址。一个由正常的内存分配器分配出来的地址都是对齐的，但此处错误的被改写为奇数。

   这个错误也不太可能是由内存越界写造成的，因为在这一长片内存中，只有一个指针异常。

   最大的可能是：某个对象被删除，但其指针还在使用造成的，所谓悬空指针问题。

   那么，导致是这个出问题的对象指针悬空，还是另一个对象指针悬空影响的呢？

   最大的可能是，这个出问题对象所占据的内存空间，曾经被别的对象使用过。但是前任使用者释放了内存，却在某处保留了指针。然后出问题的对象复用了这块地址。

   做这个判断是因为，如果出问题的对象本身是悬空指针，那么后来者占用了它的内存的话，应该成片的改写。

   从现象可以推断，内存异常一定是对原有数据进行递减造成的，而不是简单的覆盖了一个新的值。

   从退出时出错可以判断，这个 C++ 对象在有效生命期间很有可能一直是正常的，否则指针错误很可能很早就暴露出来了。

   那么，我认为最大的可能性就是：有另一个 C++ 采用了引用计数的机制。这个对象曾经引用到 0 而被正确的析构并释放掉了。但某种原因在另一个地方还保留了针对它的 raw 指针。

   这个被释放掉的对象的内存被后来的出问题的这个 C++ 对象复用，一系列的退出析构操作导致了一系列的对象析构函数的调用。那个悬空的 raw 指针被调用了。这个指针指向的对象没有虚表，所以它的析构函数可以正确的执行。引用计数这个量存在的位置恰巧在后来出问题的 C++ 对象的中间。

   减引用的函数把这个位置的值，也就是另一个对象的指针作为数值减了 1 ，发现不到 0 就跳过了。接下来的析构操作到这个位置时，访问了不正确的指针。这里期盼的指针引用的对象有虚表，偏移的差别导致跳转到虚析构函数出错。

   从电话里可以获得的信息有限，我的推断只能到这里了。

   为了进一步的盘查错误，我建议：把所有的对引用计数的操作，包括标准库中的智能指针的代码，都加上 assert 判断。断言所有的引用计数的值都应该在 0 到 10000 之间。

   我并不是说智能指针的实现会有问题，尤其是采用标准库的实现一定没有问题。

   但是，当一个对象本身被释放后，它的(悬空)指针还可以被调用析构函数却是一个隐患。悬空指针调用的对象中如果有一个智能指针的话，那么这个智能指针的析构函数依旧是会做递减操作的。

   顺便吐槽 C++ 。

   我现在看到的这个 C++ 项目，如果用一个标准的 windows 下的 malloc ，也就是一个性能比较低下的内存管理器，性能简直不能接受。你必须换一个非常优秀的内存管理器才能正常工作。这样的依赖内存分配器的性能，在我见过的 C 开发的项目中几乎不可能存在。

   这是因为 C++ 的项目多半层次混乱。我说的混乱，不一定指开发逻辑层次上的混乱，而是假借高性能之名，看起来在源代码层次把软件的层次分清楚了，但是在二进制层面却是混杂在一起的。

   一个小小的内存管理模块，就穿插于最底层到最上层。

   一个层次分明的系统，在物理上就应该是相互隔离的，这种隔离，仅仅存在于人阅读的源代码层是绝对不够的。这就好比 OS 管理下的应用进程，它绝对不依赖应用进程的程序的工作正常，不依赖应用进程准确的申请和释放资源。而是当应用进程结束后，干净的回收它申请过的所有东西。

   小到同一进程下的软件，也理所当然要按这个思路进行才对。C++ 不强调这一点，反而鼓励程序员生产出庞大的软件，并美其名曰：信任程序员。但却把用 C++ 的程序员引向一条邪路。信任程序员和放任程序员是两码事。