一个很有意思的序列化崩溃问题 -- 简化问题找到根源

一个很有意思的序列化崩溃问题

现象是这样的，我们的一个C++Appplication 打开一个 以前版本的文件，崩溃。而且从崩溃的地方看很难看出是什么原因的崩溃的，因为崩溃在CObList中。

我想做过S3K的人都知道我们做本版兼容问题的方法，就是存储当前的版本号，然后作一定的处理。

从当时的崩溃Context我找不出任何线索，是什么原因崩溃的，看上去像是 Heap破坏，因为其中一个序列化出来的　CObject的vptb是垃圾数据。然后是使用Application Verifier

来监控程序，运行也没有发现 Heap破坏的问题。这样半天时间也没查出个所以然来。

后来仔细思考，检查各个本版中序列化的主要的change, 没有什么发现。最后发现一个主要的变化，就是当前版本是unicode编译，而以前是multibyte

想起了这个，我怀疑是CString序列化会有问题，我写了个小程序作试验，分正就是用CFile 和CArchive来保存一个字符串到二进制文件，一开始用Multibte编译保存，然后用Unicode编译，并打开文件，发现绝然没有问题，呵呵

仔细看CString的实现，发现它内部的做了相应的处理，会转换。经过一系列的排查，发现是在序列化LOGFONT结构的时候会出问题，因为这个结构有个成员是TCHAR数组，这个肯定会有问题，最后修正方法也简单，我就是把读出来的char数组，转换为一下就可以了

我的问题是，如果我没有怀疑到Unicode支持的问题上，一般我们怎么快速定位序列化兼容性的问题呢？

我的想法是进行数据简化. 1,用老版本软件打开这个文件,简化文件内容,保存 2,用新版本软件打开 3,重复步骤1和2,直到找到兼容有问题的对象,再设断点跟踪