Release 崩溃 Debug 不崩？
在夸克2.0版本，出现一个在release 下必崩的问题。经过一轮排查，终于发现问题的根源所在。排查过程相当耗时，故记录下来，方便以后学习。
排查过程比较冗长。看不下的，可以直接查看结论。
0x1 崩溃日志
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x0
Crashed Thread: 1
Thread 1 Crashed:
0 libobjc.A.dylib 0x0000000189f35e34 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 68
1 Quark 0x0000000100590494 __65-[CMSDataModel saveSubRes:resCode:subResUrl:decompress:callback:]_block_invoke (CMSDataModel.mm:258)
2 libdispatch.dylib 0x000000018a36e9e0 _dispatch_call_block_and_release + 24
3 libdispatch.dylib 0x000000018a36e9a0 _dispatch_client_callout + 16
4 libdispatch.dylib 0x000000018a37d0d4 _dispatch_queue_override_invoke + 644
5 libdispatch.dylib 0x000000018a37ea50 _dispatch_root_queue_drain + 540
6 libdispatch.dylib 0x000000018a37e7d0 _dispatch_worker_thread3 + 124
7 libsystem_pthread.dylib 0x000000018a577100 _pthread_wqthread + 1096
8 libsystem_pthread.dylib 0x000000018a576cac start_wqthread + 4
从崩溃日志知道，崩溃发生的原因是访问了无效的地址0x0（SIGSEGV），查看崩溃的调用现场，很直接，崩溃的发生的地方在：
[CMSDataModel saveSubRes:resCode:subResUrl:decompress:callback:]
下面贴出关键段的代码：
dispatch_async(self.ioQueue, ^{
BOOL ret = NO;
NSFileManager *fileManager = [[NSFileManager alloc] init];
do
{
NSString *path = [self subResFilePathOfOnline:resCode subResUrl:subResUrl filePath:nil createDir:YES];
if (![subResData writeToFile:path atomically:YES])
{
[fileManager removeItemAtPath:path error:nil];
break;
}
if (bDecompress)
{
ZipArchive *archive = [[ZipArchive alloc] init];
if (![archive UnzipOpenFile:path])
{
[fileManager removeItemAtPath:path error:nil];
[archive UnzipCloseFile];
break;
}
//再次访问Self的时候发生崩溃
NSString* tempFolder = [self subResFolderOfOnline:resCode subResUrl:subResUrl isTemp:YES];
if (![archive UnzipFileTo:tempFolder overWrite:YES])
{
[fileManager removeItemAtPath:path error:nil];
[fileManager removeItemAtPath:tempFolder error:nil];
[archive UnzipCloseFile];
break;
}
[fileManager removeItemAtPath:path error:nil];
[archive UnzipCloseFile];
NSString *resFolder = [self subResFolderOfOnline:resCode subResUrl:subResUrl isTemp:NO];
if ([fileManager fileExistsAtPath:resFolder])
{
[fileManager removeItemAtPath:resFolder error:nil];
}
if (![fileManager moveItemAtPath:tempFolder toPath:resFolder error:nil])
{
[fileManager removeItemAtPath:tempFolder error:nil];
}
}
ret = YES;
} while (NO);
if (callback)
{
dispatch_async(dispatch_get_main_queue(), ^{
callback(ret, resCode, subResUrl);
});
}
});
因为崩溃只发生在release包，所有把scheme改成release，模拟案发场景。果然程序很快崩溃在：
NSString* tempFolder = [self subResFolderOfOnline:resCode subResUrl:subResUrl isTemp:YES];
访问self 的时候崩溃了！这看起来不可能呀！
确定的是self 是肯定不会被释放的，而且也不存在多线程读写的问题。那么访问self怎么就会崩溃了呢！这不科学呀！
当时因为赶着发包，需要马上解决这个问题。经过几轮修改，最后的解决方案是，把do ,while 语句去掉（我也不知道为什么想到这么改）。发现居然解决了崩溃问题，那时候怀疑的是编译选项的问题。但是好像也说不过去呀，关do while毛线事呀。
劲总问起，因为还没清楚原因，只是说把do while 改了就修复崩溃了，怀疑与编译选项优化有关。
嗯嗯，问题解决了，先发包吧！
0x2 你良心不会痛吗？
正式包上线后，问题被修复了。但是这么严重怪异的崩溃问题，就这么敷衍的修复了？会不会掩盖了更严重的问题呀？
于是决定研究一下，防止以后再遇到这种问题而无从入手。既然可能是因为编译选项的问题，那么先从汇编上分析一下吧。以下是用hopper查看该函数的汇编代码（部分）：
// 0x100d81000 + 0x8d0 定位到 NSFileManager
0000000100551e28 adrp x8, #0x100d81000
0000000100551e2c ldr x0, [x8, #0x8d0]
// 0x100d5c000 + 0xe00 定位到 alloc
0000000100551e30 adrp x8, #0x100d5c000
0000000100551e34 ldr x23, [x8, #0xe00]
0000000100551e38 mov x1, x23
0000000100551e3c bl imp___stubs__objc_msgSend
// 0x100d5c000 + 0xcd8 定位到 init
0000000100551e40 adrp x8, #0x100d5c000
0000000100551e44 ldr x22, [x8, #0xcd8]
0000000100551e48 mov x1, x22
0000000100551e4c bl imp___stubs__objc_msgSend
0000000100551e50 mov x19, x0
0000000100551e54 ldp x0, x2, [x20, #0x20]
0000000100551e58 ldr x3, [x20, #0x30]
// 0x100d72000 + 0x250 定位到 subResFilePathOfOnline:subResUrl:filePath:createDir
0000000100551e5c adrp x8, #0x100d72000
0000000100551e60 ldr x1, [x8, #0x250]
0000000100551e64 orr w5, wzr, #0x1
0000000100551e68 movz x4, #0x0
0000000100551e6c bl imp___stubs__objc_msgSend
0000000100551e70 mov x29, x29
0000000100551e74 bl imp___stubs__objc_retainAutoreleasedReturnValue
0000000100551e78 mov x21, x0
0000000100551e7c ldr x0, [x20, #0x38]
// 0x100d5d000 + 0x120 定位到 writeToFile:atomically:
0000000100551e80 adrp x8, #0x100d5d000
0000000100551e84 ldr x1, [x8, #0x120]
0000000100551e88 orr w3, wzr, #0x1
0000000100551e8c mov x2, x21
0000000100551e90 bl imp___stubs__objc_msgSend
0000000100551e94 tbz w0, 0x0, -[CMSDataModel saveSubRes:resCode:subResUrl:decompress:callback:]+972
0000000100551e98 ldrb w8, [x20, #0x48]
0000000100551e9c cbz w8, -[CMSDataModel saveSubRes:resCode:subResUrl:decompress:callback:]+1000
// 0x100d84000 + 0x110 定位到 ZipArchive
0000000100551ea0 adrp x8, #0x100d84000
0000000100551ea4 ldr x0, [x8, #0x110]
0000000100551ea8 mov x1, x23
0000000100551eac bl imp___stubs__objc_msgSend
0000000100551eb0 mov x1, x22
0000000100551eb4 bl imp___stubs__objc_msgSend
0000000100551eb8 mov x22, x0
// 0x100d72000 + 0x258 定位到 UnzipOpenFile
0000000100551ebc adrp x8, #0x100d72000
0000000100551ec0 ldr x1, [x8, #0x258]
0000000100551ec4 mov x0, x22
0000000100551ec8 mov x2, x21
0000000100551ecc bl imp___stubs__objc_msgSend
0000000100551ed0 tbz w0, 0x0, -[CMSDataModel saveSubRes:resCode:subResUrl:decompress:callback:]+1008
//按照调用约定，,x0 寄存器保存self，x0 = x20+0x20 , x0作为函数调用的第一个参数传入。但是发现x0 寄存器的值是0x20，导致访问self 的时候发生崩溃。这是典型的空指针问题呀～～～
0000000100551ed4 ldr x0, [x20, #0x20]
0000000100551ed8 adrp x8, #0x100d72000
那么关键是要看x20寄存器的值，究竟是谁动了x20寄存器！
0x3 谁动了x20寄存器
发生崩溃的原因很明显，就是x20的值被修改了，只要查出是谁动了0x20寄存器，就知道这是谁的pot了。
1.png
在执行bl 0x1009aaac4前，通过lldb查看$x20+0x20地址上的值是多少。
bl 0x1009aaac4 执行后，x20 就被修改了。那么关键就要看：bl 0x1009aaac4做了什么。下面是调用0x1009aaac4 后的汇编代码：
2.png
x20 的值保存在sp+0x10上，待函数执行完后，x20重新恢复原来的值，x20 = sp+0x10.那么关键点就落在 观察sp+0x10是否被修改。观察一个地址是否被修改，可以通过设置watchpoint来观察。
(lldb) watchpoint set expression $sp+0x10
接着继续执行，断点果然被命中了！
3.png
sp 存入x1 后，紧接着就去调用unzGetGlobalInfo 。
4.png
x1+0x10 其实就是sp+0x10 ,x1+0x10 被修改成0 。接着函数返回后，
5.png
0x1008607dc <+84>: ldp x20, x19, [sp, #0x10]
x20 = sp + 0x10 = 0。
x20+0x20 = 0x20 这就是访问的非法地址！
最后问题的关键在于unzGetGlobalInfo 函数，为什么它会修改 x1+0x10 的值？后面会解析，现在先看看为什么在debug下没有问题。
0x4 为什么开发的时候没问题呀？ --- Debug with Debug scheme
同样的，通过打断点，查看unzGetGlobalInfo 函数的汇编代码。
6.png
这汇编代码和release下看起来不像是同一份代码呀！难道有两个zip库！
接下来就尴尬了，项目里面真的有两个zip库，unzGetGlobalInfo 的实现是不一样的。
A 版本的：unzGetGlobalInfo
typedef struct unz_global_info_s
{
uLong number_entry; /* total number of entries in
the central dir on this disk */
uLong size_comment; /* size of the global comment of the zipfile */
} unz_global_info;
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;
}
B 版本的：unzGetGlobalInfo B
typedef struct unz_global_info64
{
unsigned long long number_entry; /* total number of entries in
the central dir on this disk */
unsigned long number_disk_with_CD; /* number the the disk with central dir, used for spanning ZIP*/
unsigned long size_comment; /* size of the global comment of the zipfile */
} unz_global_info64;
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;
}
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;
}
s->gi 在A版本和B版本的结构体类型是不一样的，从上面的汇编代码知道，*pglobal_info=s->gi; 是关键的步骤，会不会由于A版本的unzGetGlobalInfo 函数用了B版本的s->gi 结构体类型呢？导致赋值的时候发生错误。
0x5 删除多余的zip 库
对于上面的假设，可以删除其中一个zip 库来验证。实验证明，删除多余的zip 库后，在release scheme 下，不会崩溃了！
结论
结论很简单，就是因为用了两个zip 库，导致编译器编译的时候，发生一些奇异的问题（本人对编译器不是很熟悉，后面有时间再研究学习一下）。大家遇到在release下崩溃，debug不崩的情况，不妨考虑一下是否有两份一样的代码。
遗留的问题
- 两份zip 代码，为什么没有报duplicate symbols。
- 编译器是如何选择哪一份代码编译的。
遗留的问题在这里可以查看!
读者福利！
夸克浏览器下载快捷通道
