背景
接上一篇文章Release 崩带猴，Debug不崩？ 里面遺留了兩個問題：
- 兩份zip 代碼埠褪，為什么沒有報duplicate symbols浓利。
- 編譯器是如何選擇哪一份代碼編譯的。
最近在看一些私有API的掃描钞速，里面有涉及無用Selector的東西贷掖。而無用Selector是通過LinkMap 與mach-o 文件結合得出的，突然渴语，靈機一動苹威！
對呀！答案就在LinkMap里面呀驾凶！
因為LinkMap里列出了編譯后的每一個.o目標文件的信息（包括靜態(tài)鏈接庫.a里的）牙甫，以及每一個目標文件的代碼段，數(shù)據(jù)段存儲詳情调违。那么就可以知道當存在兩份類名一樣的代碼窟哺，編譯器是如何選擇的。
廢話不說了技肩，來看看LinkMap 吧且轨！
LinkMap
從上面截圖可以知道，編譯器最終選用的是unzip 是SSZipArchive庫里面的虚婿。而unzip 在編譯的時候其實是有兩份的旋奢，從Xcode 編譯log里面可以看到：
一份是從基礎庫UCFoundations引入的，另一份是從Pod引入的然痊。UCFoundations定義為版本A至朗，Pod 引入的zip庫定義為版本B。
Problem ?
- unz_global_info 結構在兩個版本的zip庫是不一樣的
- 同理剧浸，unzGetGlobalInfo 實現(xiàn)也是不一樣的
回顧之前崩潰的相關代碼锹引，如下圖所示：
接著看看ZipArchive 類。
這里我注意到兩點：結構體unz_global_info 和 unzGetGlobalInfo函數(shù)辛蚊，這也是導致崩潰的關鍵地方粤蝎。分別來詳細看看這兩點吧！
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函數(shù)UnzipOpenFile 里面用到的結構體globalInfo類型是unzipInfoA.但是編譯器最終鏈接的unzip是版本B的秸应，并非版本A的虑凛。也就是說unz_global_info定義用的是unzipInfoB碑宴。
很明顯這里發(fā)生類型不一致的問題！會有什么問題桑谍？接著看延柠。。锣披。
unzGetGlobalInfo 函數(shù)
- 版本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 函數(shù)里面調用的unzGetGlobalInfo應該是版本A的 贞间，但是我們知道編譯器最后鏈進去的是版本B。也就是說雹仿，UnzipOpenFile 函數(shù)里面調用的unzGetGlobalInfo是版本B的增热。
驗證猜測！下面是ZipArchive 在Release包的反匯編代碼：
接著看一下0x100202ae0：
果然胧辽，猜測正確峻仇！由于UnzipOpenFile調用的unzGetGlobalInfo的版本不對，加上在UnzipOpenFile中的globalInfo結構體類型（unzipInfoA）邑商，和函數(shù)unzGetGlobalInfo 指定參數(shù)pglobal_info32(unzipInfoB) 的類型不一樣摄咆。 導致某些寄存器的值被莫名其妙的修改了。
那么在Debug 會是怎樣呢人断？下面是ZipArchive 在Debug包的反匯編代碼：
一樣是調用了Pod版本的unzGetGlobalInfo函數(shù)吭从，那為什么不崩潰？應該是編譯優(yōu)化的問題恶迈。
結論
- 從Xcode build log 可以知道涩金，兩個版本的zip 庫都被編譯了。
- 從LinkMap 文件定位到最后鏈到程序的是版本B的zip 庫蝉绷。
- UnzipOpenFile函數(shù)沒有按照常理使用版本A的unzGetGlobalInfo函數(shù)鸭廷，而是使用了版本B的，導致崩潰熔吗。
