Release 崩，Debug不崩？--- 遗留问题解答

背景

接上一篇文章Release 崩，Debug不崩？ 里面遗留了两个问题：

• 两份zip 代码，为什么没有报duplicate symbols。
• 编译器是如何选择哪一份代码编译的。

---

最近在看一些私有API的扫描，里面有涉及无用Selector的东西。而无用Selector是通过LinkMap 与mach-o 文件结合得出的，突然，灵机一动！

对呀！答案就在LinkMap里面呀！

因为LinkMap里列出了编译后的每一个.o目标文件的信息（包括静态链接库.a里的），以及每一个目标文件的代码段，数据段存储详情。那么就可以知道当存在两份类名一样的代码，编译器是如何选择的。

废话不说了，来看看LinkMap 吧！

LinkMap

从上面截图可以知道，编译器最终选用的是unzip 是SSZipArchive库里面的。而unzip 在编译的时候其实是有两份的，从Xcode 编译log里面可以看到：

一份是从基础库UCFoundations引入的，另一份是从Pod引入的。UCFoundations定义为版本A，Pod 引入的zip库定义为版本B。

Problem ?

• unz_global_info 结构在两个版本的zip库是不一样的
• 同理，unzGetGlobalInfo 实现也是不一样的

回顾之前崩溃的相关代码，如下图所示：

接着看看ZipArchive 类。

4.png

这里我注意到两点：结构体unz_global_info 和 unzGetGlobalInfo函数，这也是导致崩溃的关键地方。分别来详细看看这两点吧！

unz_global_info

• 版本A的unz_global_info定义如下：

typedef struct unz_global_info_s
{
    uLong number_entry;   
    uLong size_comment;  
} unz_global_info;

把它定义为unzipInfoA。

• 版本B的unz_global_info定义如下：

typedef struct unz_global_info_s
{
    unsigned long number_entry;  
    unsigned long number_disk_with_CD; 
    unsigned long size_comment;  
} unz_global_info;

把它定义为unzipInfoB。
ZipArchive函数UnzipOpenFile 里面用到的结构体globalInfo类型是unzipInfoA.但是编译器最终链接的unzip是版本B的，并非版本A的。也就是说unz_global_info定义用的是unzipInfoB。

很明显这里发生类型不一致的问题！会有什么问题？接着看。。。

unzGetGlobalInfo 函数

• 版本A的：unzGetGlobalInfo

extern int ZEXPORT unzGetGlobalInfo (file,pglobal_info)
    unzFile file;
    unz_global_info *pglobal_info;
{
    unz_s* s;
    if (file==NULL)
        return UNZ_PARAMERROR;
    s=(unz_s*)file;
    *pglobal_info=s->gi;
    return UNZ_OK;
}

对应的汇编代码是这样的：

---

• 版本A的：unzGetGlobalInfo

extern int ZEXPORT unzGetGlobalInfo(unzFile file, unz_global_info *pglobal_info32)
{
    unz64_s *s;
    if (file == NULL)
        return UNZ_PARAMERROR;
    s = (unz64_s *)file;
    /* to do : check if number_entry is not truncated */
    pglobal_info32->number_entry = (uLong)s->gi.number_entry;
    pglobal_info32->size_comment = s->gi.size_comment;
    pglobal_info32->number_disk_with_CD = s->gi.number_disk_with_CD;
    return UNZ_OK;
}

对应的汇编代码是这样的：

在UnzipOpenFile 函数里面调用的unzGetGlobalInfo应该是版本A的 ，但是我们知道编译器最后链进去的是版本B。也就是说，UnzipOpenFile 函数里面调用的unzGetGlobalInfo是版本B的。

验证猜测！下面是ZipArchive 在Release包的反汇编代码：

接着看一下0x100202ae0：

果然，猜测正确！由于UnzipOpenFile调用的unzGetGlobalInfo的版本不对，加上在UnzipOpenFile中的globalInfo结构体类型（unzipInfoA），和函数unzGetGlobalInfo 指定参数pglobal_info32(unzipInfoB) 的类型不一样。 导致某些寄存器的值被莫名其妙的修改了。

那么在Debug 会是怎样呢？下面是ZipArchive 在Debug包的反汇编代码：

一样是调用了Pod版本的unzGetGlobalInfo函数，那为什么不崩溃？应该是编译优化的问题。

结论

• 从Xcode build log 可以知道，两个版本的zip 库都被编译了。
• 从LinkMap 文件定位到最后链到程序的是版本B的zip 库。
• UnzipOpenFile函数没有按照常理使用版本A的unzGetGlobalInfo函数，而是使用了版本B的，导致崩溃。