背景
接上一篇文章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 类。
这里我注意到两点：结构体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的，导致崩溃。
