[微信iOS]& 聊聊苹果的Bug - iOS 10 nano_free Crash
聊聊苹果的Bug - iOS 10 nano_free Crash
背景
iOS 10.0-10.1.1上，新出现了一类堆栈为nano_free字样的crash问题，困扰了我们一段时间，这里主要分享解决这个问题的思路，最后尝试提出一个解决方案可供参考。
它的crash堆栈大致为：
-
这种crash我们并不陌生，一般野指针的问题，也是这样的堆栈。但在iOS 10发布之后，这类crash就嗖地窜到了微信的crash排行榜的前列，而此时微信并没有发布新版本。
-
通过和一些内部、外部团队的交流，发现这是个共性问题，例如：https://forums.developer.apple.com/thread/63546
这两种迹象表明，这很可能是苹果的bug。按流程，我们向苹果提了bug report，并得到回复：“iOS 10.2 Beta有稳定性提升”。
终于等到iOS 10.2 Beta发布，我们重新统计了此类crash的系统版本分布。发现不仅在10.2 Beta正常，而且iOS 9也没有crash。
苹果给我们的建议是：“引导用户升级系统”。这当然能解决问题，但用户升级系统是个漫长的周期。
而其实我们非常关注这个问题的原因，不仅是线上版本的crash，更是在我们的开发分支，它的crash概率异常的高。如果不搞清楚触发crash的原因，那这将是一颗定时炸弹，不知道何时就会被我们合入主线，发布出去。因此我们着手开始做一些尝试。
尝试
首先我们的切入点是iOS 9和10.2 Beta没有crash。既然如此，能否将正常的代码合入微信，替换掉系统的呢？
尝试一：替换dylib
各版本的dylib可以在macOS的~/Library/Developer/Xcode/iOS DeviceSupport/找到，我们选了iOS 9.3.5的libsystem_malloc.dylib。尝试编入时却报链接错误：
ld: cannot link directly with /Users/sanhuazhang/Desktop/TestNanoCrash/libsystem_malloc.dylib. Link against the umbrella framework 'System.framework' instead. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
这个是因为dylib的LY_SUB_FRAEWORK段指明它属于System.framework，直接被编译器拒绝了。看来没有办法。（如果有同学知道如何绕过这个保护，烦请赐教。）
尝试二：编入源码
libsystem_malloc.dylib的源码可以在 https://opensource.apple.com/tarballs/libmalloc/ 找到。这里有多个版本，用otool找到iOS 9.3.5对应的源码是libmalloc-67.40.1.tar.gz。
然而这份源码是不完整的，只能读不能编译。看来这个方法也行不通。
阅读源码
上述两个方法不行，就有点束手无策了，只能阅读源码，尝试找突破口。
在libsystem_malloc.dylib中，对内存的管理有两个实现：nano zone和scalable zone。他们分别管理不同大小的内存块：
其中nano zone分配nano类型的指针，而scalable zone则分配其他三种类型。nano zone的管理区间和scalable zone是有重叠的，可以理解为nano zone是scalable在小内存下的一个优化。
这两种方法通过MallocZoneNano的环境变量进行配置：
-
当
MallocZoneNano=1时，default zone为nano zone，不满足nano zone的内存会fall through到它的helper zone，而helper zone是一个scalable zone。 -
当
MallocZoneNano=0时，deafult zone为scalable zone。
通过getenv("MallocZoneNano")可以拿到环境变量的值，我们发现，在iOS 9和iOS 10.2 Beta中，MallocZoneNano=0，而其他系统MallocZoneNano=1。
换句话说，苹果并不是修复了这个问题，而只是屏蔽了。因此其实我们在尝试一中提到替换dylib，即使替换成功，也是不解决问题的。
结合最初的crash堆栈，我们知道crash是发生在nano zone内的，那是否可以关掉nano zone呢？
尝试三：修改环境变量MallocZoneNano=0
-
通过
setenv方法，可以设置环境变量，修改MallocZoneNano=0。然而并没有效果，因为dylib的初始化在微信之前，此时微信还未启动。 -
根据苹果的文档，Info.plist的
LSEnvironment字段，可以设置环境变量，然而这个只适用于macOS。 -
在Xcode的Schema里设置
MallocZoneNano=0后，本地不再出现crash。但schema只适用于调试阶段，不能编进app里。
看来这个方法也行不通，但起码验证了，关掉nano zone是可以解决问题。
尝试四：hook
既然无法完全关闭nano zone，那就尝试跳过它。
因为我们自己通过malloc_zone_create创建的zone都属于scalable zone，不会导致crash。因此我们可以
-
通过malloc_zone_create创建一个新的zone，并命名为guard zone
-
用fishhook，将malloc和malloc_zone_malloc等一众常用的内存管理的方法，转发到guard zone
使用这个方案后，crash的概率确实降了一些。但并不彻底解决问题。
因为fishhook无法hook掉其他dylib的调用，也就是说，系统的调用（如Cocoa、CoreFoundation等）依然是走nano zone。
尝试五：跳过nano zone
从上面我们知道，nano zone管理的是0-256字节的内存，如果内存不在这个区间，则会fall through到helper zone。而zone的结构是公开的：
那么可以用tricky一点的方法：修改nano zone和helper zone的函数指针，让nano zone的内存申请虚增，超过256字节，以骗过nano zone，而fall through到helper zone后，再恢复为真正的大小。以malloc为例，具体实现为：
由于内存有限，size的最高位一般不会被使用，因此我们可以用这一位来标记。
当我满心以为终于解决问题时，却发现，crash概率不仅没有降低，反而到了几乎必现的程度。而此时除了少数在替换前就申请的内存是走的nano zone，其他内存都是在scalable zone内被管理。这一现象不禁让人怀疑，nano_free的crash，很可能是zone判断错误。即在scalable zone申请的内存，却在nano zone中释放。
重现问题
为了验证，我们还得从源码中搞清楚怎么区分一个指针属于nano zone还是scalable zone：
可以看到，在x86下，是通过获取指针地址所属的段来判断zone的。当signature满足0x00006这个段时，则属于nano zone。
虽然这份代码里没有提供arm下的判断方式，但可以结合源码中对signature判断的函数，并通过符号断点，很快就能找到arm下比较signature的汇编。
即：当ptr>>28==0x17时，属于nano zone。
通过测试代码可以发现，小于256字节的指针确实在0x17段。然而，代码跑了一阵子之后，大于256字节的指针也落在了0x17段。
似乎我们已经很接近问题的核心了。再来一段测试代码验明真身。
先通过循环不断地申请257字节的内存，并保存起来。这些内存应该都落在scalable zone中。当出现0x17段的内存时，我们break掉。
可以假设在此之后scalable zone内申请的内存，都在0x17段，具体代码为：
我们新建了一个iOS的Single View Application，除了这段代码，没有做其他任何的修改。问题重现了：
解决方案
从重现的代码来看，要真正规避nano_free类型的crash出现，只能是减少内存的使用，但这并不好操作。因此，解决思路还是回到保护上。
结合上面提到尝试3和4，我们进行了这样的修改。
-
创建一个自己的zone，命名为guard zone。
-
修改nano zone的函数指针，重定向到guard zone。
-
对于没有传入指针的函数，直接重定向到guard zone。
-
对于有传入指针的函数，先用size判断所属的zone，再进行分发。
这里需要特别注意的是，因为在修改函数指针前，已经有一部分指针在nano zone中申请了。因此对于每个传入的指针，我们都需要找到它所属的zone。代码示例为：
注：
-
该问题不止有一种方式解决，可自行发散思维。
-
这种方式目前还在灰度中，若要使用，请搭配适当的灰度和回退措施。
微信扫一扫
关注该公众号
T
