汇编还是不能丢啊

最后还是通过看汇编代码定位了问题。有位同事在用数组的时候不检查下标，结果在并发状态下刷到了 -1。不过问题的根源还是线程安全性。底层数据引擎设计时并没考虑并发问题，因此才会在正常工作的时候变出非法的数据出来。

借此机会又再次温习了汇编语言，大学时候学的 8086 / 8088 汇编指令虽然早已过时，但思想还算没忘。那些关于现在的大学念了白念的说法，我觉得还是需要探讨。

之前用 tds2dbg 完成的工作也有价值，帮我把代码段确定了。C++ 代码能定位到就这一两句，那么再来对照汇编指令就比较好理解了。

另外，今天还学习到了 LEA 指令的相关知识，顺便网摘一篇对我有点帮助的博文：
http://www.cnitblog.com/textbox/articles/51912.html

掌握了更好的 BCB 程序调试手段

Borland C++ Builder 5 编译的程序没有 PDB，因此要通过 Dump 文件来分析故障原因就太坑爹了。没有符号文件的话，汇编看起来相当痛苦。
上次查过，有个办法是使用 map2dbg，把 map 文件转换成 dbg 文件，这样 windbg 也能够加载符号文件用于调试。不过 map 里面只有函数名称，没有代码的行号，所以调试起来还是不是很方便。如果断点是在一个长长的函数里面，而且没有嵌套调用什么函数，那么对于汇编功底不深的我也是一样的郁闷。

今天下了点决心要解决这个问题，否则调试效率太低了。
感谢万能的 Google，这次我知道了有个开源项目叫 tds2dbg。用法和 map2dbg 类似，生成的 dbg 文件的确可用，而且在正确的行号上指出了我遇到的问题。这样，Crash 就不再是一个问题了。

值得注意的是：BCB 编译选项中，必须打开 Compiler->Debugging->Line Number Information，以及 Linker 里面的 Create debug information。否则生成的 dbg 文件没法用。

遇到 Bug 就像踩了地雷

大约是八月份的时候，应公司的要求，设计了一个给各产品线通用的日志模块。简单而言，也就是做一个导出 C 函数的 DLL，实现通用的日志读写和管理功能。设计是我做的，实现就交给了另一个同事。然而这个同事没过多久就离职了，因此交接时把草草地写完的代码又回到了我这里来。

平心而论，这段代码写得不怎么样。估计这位同事当时已经心不在焉了，只想早早结束了事吧。代码中充满了他此前做过的一个 BCB 项目的风格，主要的功能是用 C 风格的代码来实现（例如文件读写等），而工程又是一个 VC6 的 Win32 DLL，里面写了自己的类等等。我看了之后第一感觉就是想推了重写，好不容易才压制住这种想法。
当时我给自己安排了两天来接收并改造这些代码，后来拖长到了三四天。其实现在想想还不如重构。给我的代码功能测试都通不过，里面 Bug一大堆。我这人又是有一点代码洁癖的家伙，遇到空格缩进什么的都忍不住花时间去调。最后终于弄好了，真有点不想再去碰了，虽然我知道值得改进的地方还很多。

结果今天就碰到了一个藏在其中的 Bug。

这个日志模块被设计为保存加密日志，目的嘛……是为了防止用户抵赖。加密就不能全文加密，否则每来一条日志都得解密再加密，量稍微一大就死翘翘了。差分加密是必须的。设计的时候是对每一条日志的内容进行加密，只留下必要的信息放在每一条的头部以便索引。从性能和安全性方面权衡，当时选择了 AES 算法。
代码交到我手上时，之前那个同事大概已经从网上找了一段 AES 算法封装好了。既然能实现加密解密的功能，我也就没往里面细看。谁知道这玩意儿是线程不安全的。今天专拣双核机器报错，从 fseek 到 fopen 查了一圈，终于怀疑到这个 AES 算法上。浪费了约两个小时时间。

我估计我有时间可能真得把它给重写了，里面指不定还有什么问题。

VC 和 BCB 那点事——DLL 导出函数的结构体参数

还是那个项目，VC 写一个 DLL，导出若干 C 函数，BCB 来调用。实际情况比这个复杂，不过与我这次要讲的这个问题无关，所以在此省略了。

在解决了上次遇到的虚函数表顺序问题后，继续往下调试，又碰到了一个很怪的问题。有一个导出函数，一调用便崩溃。进去一看吧，崩溃点的代码别的导出函数也在用，没什么不对。虽然改改代码，可以做到不抛出异常，但该导出函数返回的值又不正常。反正它就是干不了想干的活。

该函数本身很简单，因此怀疑不是内部逻辑导致的问题。通过对比，发现该函数与其它工作正常的导出函数有一个明显的区别：它返回了一个自定义的结构体作为返回值。函数的声明大概是这样子的：

LONDATEEX __stdcall GetDataDate( USHORT sMarket);

由于别的可能性被一一排除，因此焦点慢慢移到这个情况上来。查了查网上的信息，发现有一篇文章（被墙，由此可见 GFW 的反动性质）提到了跨模块调用时的内存管理问题，并据此总结了几条规则。其中一条，便是不要在跨模块函数调用中使用类或结构体作为参数或返回值类型。

该文章在这一点上略有阐述：因为内存管理模式不一样，所以类和结构体这种可能会进行内存分配、回收的数据类型，一旦用作跨模块调用的参数或返回值，就会导致不确定的后果。我认为这个解释是合理的。我之前也已经想到了这一点，不过接下来还有。

该文章还提出了改进建议——如果一定要作为参数或返回值传递，那么应该采用所谓的纯结构体，即只包含了简单数据类型的结构体，构造、析构时不涉及内存分配和释放。该文认为，这种纯结构体的数据类型，可以用于 DLL 导出函数的参数或返回值。碰巧了，我这次这个结构体，就是个纯结构体。那么按照这篇文章的理论，不应该有问题才对。

不弄明白这个问题，始终是不甘心，于是我动手做实验了。先用 VC 写了一个很简单的 DLL，声明了一个最简单的结构体，包含两个 int 类型的变量。然后用 BCB 来调用。并且，在做这个实验的时候，我特地注意避免了字节对齐不一致的问题。

嗯，结果是什么呢？调用完成了，可无论传进去的参数值还是传出来的返回值，都不对。同样的函数声明方式，都用了 __stdcall 的另一个只包含简单数据类型作为参数和返回值的 DLL 导出函数，工作正常。

两相对照，显然，就算是所谓纯结构体，也不见得能够放心地用于跨模块的函数调用。至少，在 VC 和 BCB5 之间，是会有问题的。别人说的，不一定就是对的，至少不一定全对。尽信书不如无书。

解决方案也很简单，指针是一个简单数据类型，把结构体的指针作为参数传进去就行了。比如：

BOOL __stdcall GetDataDate( USHORT sMarket, LONDATEEX* pDate);

还有别的办法也行，比如利用 COM，或者通过操作系统级别管理的对象来传递数据。总之别让两种编译器编译出来的东西去分别猜对方是怎么管理内存的就行。

VC 和 BCB 那点事——虚函数的顺序问题

因为工作需要，编写了一个 C++ 类，供一个 VC 下的 DLL 使用。用法类似回调对象，将 C++ 对象的指针传给 DLL 导出的函数。类里面要被用到的函数全是虚函数，父类是个彻底的抽象类，由 DLL 的开发人员提供 .h 头文件。VC 和 BCB 在虚函数表的实现上是一致的，因此可以跨模块调用。

大部分虚函数的调用测试都很顺利，但在一个函数上遇到了麻烦。不，应该说是两个。在测试过程中发现，当 DLL 想要调用我提供的 C++ 类的 FunA 函数时，总是错误地调用到了 FunB 函数。反过来也一样，结果就好像是 DLL 把 A 函数和 B 函数搞反了。

class A
{
    ……
    virtual FunA() = 0;
    virtual FunB() = 0;
    ……
};

既然是按照虚函数表来调用，那就跟函数名无关。这一点很快就得到了证实。现在唯一剩下的就是顺序问题。根据资料，虚函数表里面的顺序是根据函数的声明顺序来排布的，也就是说 .h 头文件决定了顺序。调换了一下顺序，果然就正常了，可为什么会反呢？

其实不能只看这么一点儿代码，这个问题和上下文有关：

class A
{
    ……
    virtual FunB(int J) = 0;
    virtual FunA() = 0;
    virtual FunB() = 0;
    ……
};

最后是 CSDN 上一篇博文揭示了这个问题：VC 会把重载函数给排在一起，不管中间有没有插队者。参见：http://blog.csdn.net/doudouhuy/article/details/4348531

也就是说，最终的顺序实际上是：

class A
{
    ……
    virtual FunB(int J) = 0;
    virtual FunB() = 0;
    virtual FunA() = 0;
    ……
};

而 BCB 大概不会做这个改动，因此调用到的函数就和预期的不一样了。

最后说一下。为了避免遇到类似问题，建议在进行跨模块的虚函数调用的时候，彻底避开重载函数出现的情况。把所有函数的名称都声明得不同，就不会轮到编译器来干扰了。

都是负数惹的祸？

十一长假之后第一天上班，继续调试那位还在婚假当中的同事留下的代码。上午查到的一个 Bug 让我相当无语。不过鉴于自己如果思想在开小差的话也很可能会犯类似错误，故记录下来警醒自己。

看看这段代码：

#define ST_ERR -1
……
BYTE result = ST_ERR;
……
if (result == ST_ERR)
    return errmsg;

事实上，这个if语句根本就没得到执行。即使 result 在赋值了 ST_ERR 之后从未改变，代码在执行时仍然跳过了判断，继续执行下面的代码。也就是说，result 明明赋值了 ST_ERR，但却不等于 ST_ERR。

难道遇到鬼了，result 中间被篡改了？溢出过？

好吧，其实 result 的确不是 -1，而是 255。看看 BYTE 的定义就清楚了。BYTE 并不是 C/C++ 内建的数据类型。在 Win32 平台上，它通常都被定义为 unsigned char。

到这里就明白了，unsigned 当然不可能有负数。而 ST_ERR 因为用了宏定义，当做常量使用的时候并不会自动转成非负的 unsigned 形式，这样当然不可能相等了。

说穿了，不是负数惹的祸，而是「宏」这个东西惹的祸。如果用 const 常量，因为常量的定义上有类型信息存在，就不会有这个问题了。

当然，这里无意评价宏与 const 常量的好与坏，单纯指出问题而已。目前这个公司的代码，宏用得不少，难保会有菜鸟程序员出这种错，隐患啊！

初始化，真的很重要

刚花了大半天的时间解决掉一个 Bug，再次证明了变量初始化的重要性。照例，还是先来看一小段代码：

map<string, TEOBJ> telist; // 全局对象
……
TEOBJ spte(3);
telist["debug"] = spte;

很简单吧？按道理这点代码应该没有什么问题。不过在最后一句中却抛出了异常，发生了崩溃。负责这部分代码的人昨天就请了假回家了，节后还有婚假，一走要近二十天，只好自己动手找原因。

这里的 TEOBJ，是一个自己定义的类。在我的这个案例中，它是一个底层库里面定义的数据对象类，用在了很多地方。基于这个前提，我首先判断这个 Bug 的故障点在赋值号的左边。

可是左边也是个 std::map 的相当标准的用法，STL 出错的可能性恐怕比我们自己的底层库更低，而且这个用法我以前也用过很多，没有出过什么问题。怀疑的眼光于是又回到了赋值号的右边。

那么到底是哪一边呢？我也拿不准了，于是排除法上马。通过几轮替换，我终于把问题基本定性为「由 TEOBJ 引起，但需要在赋值到 map 的 [] 运算符时产生」。

既然说到赋值，那么就该看看 TEOBJ 的相关声明了：

class TEOBJ {
public:
    int GroupID;
private:
    int GroupCode;
public:
    TEOBJ::TEOBJ() {};
    TEOBJ::TEOBJ(int nGroupID) {
        GroupID = nGroupID;
        GroupCode = TDataStore::Groups[GroupID]->Code;
    }
    TEOBJ::TEOBJ(const TEOBJ& r) {
        GroupID = r.GroupID;
        GroupCode = TDataStore::Groups[GroupID]->Code;
    }
    const TEOBJ& TEOBJ::operator=(const TEOBJ& r) {
        GroupID = r.GroupID;
        GroupCode = TDataStore::Groups[GroupID]->Code;
    }
};

这个 TEOBJ 重载了拷贝构造函数和赋值运算符，在其中通过查询一个数据字典确保 GroupCode 有准确的取值。

首先，赋值运算符重载这里的返回值有点小问题。const 引用类型的返回值与习惯上的 non-const 引用类型的返回值有所区别。不过这个最多造成编译时语法检查上的问题，不至于引起指针错误。

其次，就是这个 TDataStore::Groups[GroupID] 的数组的使用值得怀疑了。

实际案例比这个情况要复杂一些，而且我对于 BCB 的使用还不算熟悉，调试基本靠 OutputDebugString。问题就诡异在，往 TEOBJ::operator=() 里面只要任意加一行 OutputDebugString，故障就消失了。搞得好像是野指针一样。

我在此浪费了很多时间，走了不少弯路。后来，一咬牙用上了 windbg，配合 map2dbg，好歹是得到了 CallStack。但是 map2dbg 之后得到的符号名称又和我以前看到的有些不同，于是又错判了位置。

最后，我终于在 windbg + 排除法的协助下找到了问题。问题根本不在赋值运算符重载函数中。尽管这里代码中明显是用到了它，但它并没有出问题。抛出异常的是拷贝构造函数。这个就要从 map::operator[] 的实现说起了。

Borland C++ Builder 5 里面的 std::map，其实现代码在 map.h 里面，是一个 inline 函数。挖出来一看，倒也很简单：

mapped_type& operator[] (const key_type& k) {
    value_type tmp(k,T());
    return (*((insert(tmp)).first)).second;
}

可以看到，这里先生成了一个临时变量（其实本例中就是 pair<string, TEOBJ>）。在生成这个临时变量的时候，采用了无参数的 TEOBJ 构造函数。此时 TEOBJ::GroupID 还是没有初始化的，在 Release 版本中它可能是任意值（TEOBJ 所在的底层库就是 Release 编译）。

实际使用时，TEOBJ 都通过 TEOBJ::TEOBJ(int nGroupID) 来初始化，因此不会产生这种未被正确初始化的实例。但在 map::operator[] 中，由于是「先插入空值，再传出引用用于赋值」，这个时候就使得拷贝构造函数被调用，于是产生了类似的访问野指针的效果，导致故障的出现。

通过在拷贝构造函数中用 OutputDebugString 输出 GroupID 的取值，确认了这一点。

至此，真相大白。总结经验教训如下：

1. 变量的初始化很重要，一个也不能放松，不能因为眼下不初始化也不会出问题，就放松警惕。做底层库的人尤其应该重视——你的代码不只是你一个人在用！
2. 数组的下标，或者说指针的偏移量，这种变量与指针基本上是同样的性质。要提防野指针，它们也要算上。
3. 调试手段无所谓牛刀不牛刀，好用就用，不要因为感觉问题小、简单，就先用笨办法尝试，直到一筹莫展了之后才考虑别的办法。如果我一开始就用 windbg，时间上可能会节省更多一些。

在 STL 容器中删对象一定要小心

先来看一段代码：

typedef map<string, string> Dict;
Dict eventmap;
for (Dict::iterator pIter = eventmap.begin(); pIter != eventmap.end(); ++pIter) {
    if (pIter->second == "no")
        eventmap.erase(pIter);
}

熟悉 STL 的人都知道，这段代码是错的。出问题的可能性不是 100%，但是相当大，而且可能会是那种不一定能稳定重现的问题，往往会搞得人很恍惚。

自己很早以前就吃过这个亏，那时候还不太会用 STL。当定位到这一段代码后，凭直觉也觉得如果这样删除对象，那删除之后的 pIter 是不是正确的？可能很难讲。毕竟学过「数据结构」，大概能猜到各种容器里面的信息是如何组织的。

昨天又看见同事在这样写代码。可能他对 STL 也不熟。至少我目前对于 erase 这个单词已经产生了足够的警戒，一旦要用的时候就会想起吃过的亏来。

正确的代码应该是：

typedef map<string, string> Dict;
Dict eventmap;
for (Dict::iterator pIter = eventmap.begin(); pIter != eventmap.end();) {
    if (pIter->second == "no")
        pIter = eventmap.erase(pIter);
    else
        ++pIter;
}

另外，昨天发现 Borland C++ Builder 提供的 STL 和 VC 有点区别，map::erase 没有返回值，因此不支持这种写法。那么还有另一种办法：

        eventmap.erase(pIter++);

这样就可以了。相比之下，这种写法可能适应性更强一些。

CWebBrowser2 打开 PDF 后退出时崩溃问题的解决

用嵌入在对话框中的 CWebBrowser2 控件打开 PDF 文档后，主程序退出时抛了 Access Violation。扔异常的是 ACRORD32.DLL，ADOBE 自己的玩意儿，调用栈中也看不出什么，主程序看来都快退完了，显然和什么东西没关干净有关。

照例，国产没货。最后在这里找到了：

• http://forums.adobe.com/message/2373918（链接已失效）：贴子中的人也是一筹莫展了快一年，最后按下面的办法解决了；
• http://stackoverflow.com/questions/1359616/axacropdflib-at-closing-problem-c：简单地说，的确是没关干净。加上一句 CoFreeUnusedLibraries() 就万事大吉了。

以上方法，在 VC6 sp6 / WinXP 的 Debug 和 Release 编译上都试过。除此之外就不知道了。

据说，问题和 Adobe Reader 9 有关。V8 没有这个问题，因为 V8 是单一实例，而 V9 不是。照此一来，内存泄漏可能也是难免的。