幽灵般的无栈Crash修复记

　　作者：rayhunterli，腾讯IEG游戏客户端开发工程师
　　| 导语   本文主要对一例无栈Crash，在内网不能重现，外网没有内存dump和墓碑文件情况下；怎么通过残留寄存器值，深入结合C++汇编层面函数调用原理，根据蛛丝马迹，定位解决问题。本文应同事邀请，经审批公开，但部分图片与内容为了信息安全，会进行打码和信息脱敏，只保留技术讨论，可能有些生硬，望谅解！ 一: 问题信息与初步分析1.1 后台上报与简要分析
　　新版本上线后，进行Crash总结时，发现CrashSight后台有不少无栈上报。JAVA层栈可以忽略，Native层栈只有一行，前面文章也提过崩溃的信息栈很少， 通常来说越难查 。
　　简要分析： 只有一行栈，且PC值是一个奇怪的值，不属于某个模块.text代码段范围; 但应该是程序执行时，执行到错误的地址了；该问题栈是无法回溯，连那个模块引发的都无法确认，这个才让难度几何级增大。
　　补充：Crash基本知识可以参考我以前写的一篇总结文章：《C++中Crash定位原理与常见案例反汇编分析》
　　针对无栈问题，前不久我已经解决过一例安全模块引发的，相对简单很多，但属内网链接就不再公开。
　　少量同学对C++函数再汇编层面调用过程理解有疑问，可参考《人人都能学的会C++协程原理剖析与自我实现》, 里面有函数调用过程讨论 1.2 常规行动与分析1.观察栈信息：只有一条栈，大量查看上报的PC寄存器值，发现基本没有什么规律性，有的很大，有的看真起来还接近.text段合理值，我随意截些图，如下图所示。总之来说，乱七八糟，各种各样，没有得出什么规律。
　　可能有人看到上报错误信号不同，但BUS_ADRALN与SEGV_MAPERR都是访问到非法内存，只是内存没有对齐，可能就报BUS_ADRALN，否则SEGV_MAPERR；由于出错值目前看有点随机，当然对不齐比能对齐的多，所以本例BUS_ADRALN多。2.观察日志：CrashSight后台上报通常都带有crash发生时部分logcat日志，往常复杂的案例，通过阅读大量案例的日志，总能找到蛛丝马迹。这次我也不知道读了多少条，并没有得到特别有效的结论，除了发现大都在战斗中时出问题，别的并没有收获。3.观察其它线程栈：
　　以前的经验，有时看看其它线程调用栈，可能也发现蛛丝马迹，但这个问题，也是失败告终。4.观察硬件及状态维度信息：比如出问题机器型号，众多，和型号无关；32位还64位也没用；游戏出问题时间，有几分钟的，有几十分钟的，也有一两小时无果，说明不是启动；观察状态：比如前后台，是加载阶段，退出阶段等，有时这个信息也挺有用，结合状态日志，确定了是战斗内，只有开始标识，没有结束标识。
　　总结： 经过上面的行动处理，发现都失败，接下来有几个行动可选：1.读源码：
　　首先无栈问题，不能确定是那个模块引发的。在我们项目主要是＂xxxxxx_A.so＂，＂xxxxxx_B.so＂,＂xxxxxx_C.so＂三大模块（名称隐藏），再加上很多其他小模块及第三方模块。这次是大版本更新，改动非常多，去看代码基本不太可能。最核心的是就算看了，你也不一定能发现，这种基本排除。2.大量测试：
　　本问题如果复现了，有墓碑文件，跳过第一层栈，手动解析，基本可以秒杀。不过本案例量也不算少，也不是严重的不行，内部与少量同学沟通，进行测试，没有复现问题；这个问题没有那么容易复现，同时感觉还不到全力投入人力进行大批量测试。3.底层深入分析：
　　本问题比较乱，出现问题点比较多，只要案例多，肯定能把规律性提取出来。我相信再搞一搞，结合汇编函数调用规律，全面分析，就可能成功，实在不行，再说。4.启用CrashSight实验功能：CrashSight也提功类似内存dump功能，但我们版本只有1Mb内存上传，100条线程左右估计要3Mb。基本会截断，需要他们手动解析二进制片段，还不一定有这个栈内存，非常麻烦。再加上这个功能只有一个项目用，可能有其它影响，和CrashSight同学讨论，这个做我方案3不成功的备选。
　　我先选择3，假如失败后，计划进行2，4。二:在寄存器与汇编指令中寻找蛛丝马迹
　　在一所有失败后，仅有最有效的信息，就剩32个寄存器，我们要从这仅有的信息中，尝试揪出本问题，还是比较难。
　　2.1 探寻FP，LR，PC三个关键寄存器
　　对于我们这种情况，最核心关联的三个寄存器就是FP，LR，PC，我们项目主要模块，进行C++编译时，没有通过-fomit-frame-pointer参数强制禁用FP；（禁用时回溯栈麻烦，需要用dwarf结合EFL的.eh_frame段存放CFI信息）；通过大量阅读这些寄存器，稍微并整理了一下，大致分为下面5类类型1:lr，pc相同，看起来不正常，但FP看起来也不正常 r29=0x051f0076a392d140 r30=0x058e045c05220520 pc=0x058e045c05220520 具体CrashSight链接：xxxxxxxx(公开版隐藏)   类型2:lr，pc相同，看起来不正常，但FP看起来接近合理值 r29=0x0000007ad6ef07e0 r30=07x048304504722a88 pc=0x0483047504722a88 具体CrashSight链接：xxxxxxxx(公开版隐藏)   类型3:lr，pc相同，看起来接近合理值，但FP看起来不正常 r29=0x0485048404838210 r30=0x0000006c04880487 pc=0x0000006c04880487 具体CrashSight链接：xxxxxxxx(公开版隐藏)   类型4:lr，pc相同，看起来接近合理值，但FP看起来也接近合理值 r29=0x00000078f61faaa0 r30=0x0000007804da04d2 pc=0x0000007804da04d2 具体CrashSight链接：xxxxxxxx(公开版隐藏)  类型5:lr，pc不相同，且三个都不正常 r29=0x045d007823bf5170 r30=0x045b0459045c051f pc=0x005b0459045c051f 具体CrashSight链接：xxxxxxxx(公开版隐藏)
　　结论：各种情况都有，没有发现特别意义，真的吗？？？也不是完全没有意义，且看下一小节2.2 深入ARM分析跳转指令---得出重要推论1
　　由常识可明确本例发生在指跳转指令。
　　别看这么多跳转指令，由2.1的信息，我们很快就能锁定。1.条件跳转指令排除：
　　不看条件，他们实质是offset跳转，跳转的实际为固定值，BranchTo = PC + offset，他们不可能跳转到变态大的PC值，且LR值通常不会变（先强写一下LR除外），基本排除了。2.B指令排除：
　　由于我们现在用4字节指令，留给B指令，只有26bit的偏移，不可能跳转到变态大的PC值；且这里出错时，PC相对地址不变，排除；加上LR不变，更加排除。3.BL指令排除：
　　同上，光变态大PC的数据排除，LR实际为跳转时PC+4；这点也能排除4.BLR指令排除：
　　这个可以满足PC变态大，但必然有有通用寄存器Xn保存PC值，通过大量观察上报寄存器，找不到Xn，排除5.BR指令排除：
　　这个有时也用在函数结束，由LR提前从栈弹出，可以满足PC变态大，但必然有有通用寄存器Xn保存PC值，通过大量观察上报寄存器，找不到Xn，排除6.就你了：ret指令：
　　一般用在函数结束时，从栈内存中先弹出高位寄存器（X19----X30，根据函数需要，编译实际保存不同），如果栈内存被改写，那么LR，FP都可能是错误的值，这样就能造成符合我们要求的无栈crash。
　　ARM平台的ret指令和x86/x64平台，还是有点区别的，这点需要注意下。
　　总结：到现在，我们已经明确是在函数结束时，由于栈越界改写破坏了LR，或FP，或两者，ret指令跳转失败；这有用吗？？？有用，但只有一点点。因为到现在我们连那个所属那个模块都不知道，好像又陷入僵局。2.3 再看FP与SP寄存器--离真相更近一步
　　有了2.2小结的结论，函数返回，ret指令失败，有2.1小节我们问题是多种多样的，我们还可以观察FP与SP。
　　假设A函数调用B函数，B函数结束，ret指令失败，这时B函数的栈已经平衡了，这时我们可以推出一个重要结论：
　　SP：寄存器实际为A函数的栈顶，且不会被破坏
　　FP：寄存器如果没有被越界改写的情况下，就是A的函数的栈底
　　两者相减，就是函数A的栈大小，而一个函数的栈大小是固定的
　　于是我就挑了一些FP看似处于正常值的案例和SP相减，就得到下面的结果：r29=0x0000006f29ca5d40 r30=0x0483047504727a88 sp=0x0000006f29ca5b00 = 240H/576  r29=0x051f0076a392d140 r30=0x058e045c05220520 sp=0x00000076a392d110 pc=0x058e045c05220520 pstate=0x0000000080000000 = 30H/48 不少  r29=0x0485048404831170 r30=0x0000007d04880487 sp=0x0000007e11601140 pc=0x0000007d04880487 pstate=0x0000000020000000 = 30H/48 侵入  r29=0x051f007838a0dab0 r30=0x058e045d045c04bc sp=0x0000007838a0da80 pc=0x058e045d045c04bc pstate=0x0000000080000000 = 30H/48 侵入  r29=0x0000007ad6ef07e0 r30=0x0483047504722a88 sp=0x0000007ad6ef05a0 pc=0x0483047504722a88 pstate=0x0000000060000000 = 240H/576  r29=0x0000007e9816de60 r30=0x048304750472ca88 sp=0x0000007e9816dc20 pc=0x048304750472ca88 pstate=0x0000000060000000 = 240H/576  r29=0x000000756acd27d0 r30=0x048304750472ca88 sp=0x000000756acd2590 pc=0x048304750472ca88 pstate=0x0000000060001000 = 240H/576
　　函数A栈大小，基本上固定为240H和30H两种（其中部分30H，感觉最高16位，好像被写入奇怪的值，后面48位，看起来是合理的栈内存地址；我这里抛出最高16位相减），说明可能至少两个函数出现这种情况。用IDA搜一个主要的模块，其实栈内存为240H并不太多，30H就一大堆。
　　总结：出问题的调用者函数栈内存大小为240H，也就是576个字节，或者48字节两种；这时结合其他寄存器观察，已经感觉到越界可能2字节一组（这点还不能完全实锤）；但…好像还是没用，我们还是不知道那个模块，怎么破？？？2.4 不要放弃，再深入观察寄存器--结果呼之欲出
　　为什么不要放弃呢？因为我们这次无栈出现的寄存器杂乱，各式各样，各种组合，像幽灵一样，特征似乎不那么明显，反过来这也是好处，说明可以遍历多种出问题的情况。如果是越界，很大可能可能是一个跳跃性越界，而不是连续越界。就是这样，加上特征不明显，只要我看的多，就可能找到漏网之鱼。
　　我重点观察高位寄存器，对于异常值不断观察，再结合汇编知识，我们可以得到下面结论或推论。1.越界起始不是必然值：
　　如果从栈变量写越界栈寄存器，连续写的话，对于一个函数来说，当写到栈内存保留的寄存器时，必然是特定的，但本例不是。2.越界值似乎有点意思：
　　大量观察，发现特征也是2字节一组，且范围基本就是0x04xx，0x05xx较多。3. 寄存存越界分析：
　　C++编译器对FP开启模式，通常将FP,LR保存栈顶，如果有其它高位寄存器要保存，必然存在下面可能。* a：越界先写坏其它高位寄存器，还没写坏后面的FP，LR。这种情况，能栈回溯,但访问高位寄存器可能引发crash，那么版本必然存在常规crash!!!* b：越界写坏LR寄存器。这种情况发生时，就是我们要查的无栈Crash* c：越界写坏不是本层函数栈，更高层次的函数栈，那么可能导致更高层函数崩溃。4. 我们最想要的漏网之鱼：
　　由了上述3条结论后，我们可以寻找漏网之鱼，就是只有最高16位写坏的那种。反正本次够幽灵，规律性难概括，只要坚持看，肯定能找到，果不其然。// 很快找到，像这样越界从FP寄存器最高16bit，后面48bit是有效的 r29  =  0x051f0076a392d140   r30 =  0x058e045c05220520
　　我们只要继续再找，如果越界是LR最高16bit开始，那么我们就将秒杀这个bug
　　// 很快找到，像这样越界从LR寄存器最高16bit，后面48bit是有效的 r29  =  0x00000073313ca1d0   r30 =  0x0457007302d9a190   sp =  0x00000073313ca1a0    10   pc =  0x0057007302d9a190   pstate =  0x0000000080001000   查看模块地址： 72fe7ad000 -  73058aa000 r -  xp  00000000    103  :  13    1902513   libxxxxxxx_A .  so 可以推出结论：从45ED190地址出问题，分析相应汇编，即将秒杀！！！ 7302d9a190 -  72fe7ad000  =   45ED190
　　再找到类似的r28=0x000000742d7fc698 r29=0x00000074505bd810 r30=0x045700742ab04bb8 sp=0x00000074505bd5d0 pc=0x005700742ab04bb8 pstate=0x0000000080000000 也还是libxxxxxxx_A.so模块，可以推出结论：从45EEBB8地址出问题，分析相应汇编，即将秒杀！！ 0x0742ab04bb8-0x7426516000 = 45EEBB8
　　总结：到现在我们充分利用对汇编的理解，结合大量的寄存器的观测，不停的寻找，才得到本文最重要的推论3，4,也找到两处函数调用地址；到这基本上这个问题就秒杀了，我们只需从CrashSight后台找相关常规崩溃去验证，我们的推论成立与否就可以了。搜索蛛丝马迹到此就结束了，下面转到常规分析。三:一步一步验证推论
　　虽然知道2.4小节的结论，可能秒杀这个问题。这有点利用假设站上帝视角，还存在假设，也为了在讲述角度更好示范解常规crash，先不直接用推论，进行更加常规点分析（我自己已先看那两个推论地址与反查出的函数名，CrashSight后台果然是有对应上报的，且相同业务上报位居高位）。先看本版本新增最多相同函数名的业务有栈崩溃，这个崩溃函数段就覆盖其中45EEBB8地址，虽地址有一偏差，但感觉是同一个问题。虽然用推论可能更快，但还是先解决已明确的问题把。不过最开始统计时相关同学告诉我已经修复了，最初我没有去管。3.1 业务模块有栈新常规问题分析
　　示意图已经被我严重打码了，就是普通业务代码，一层一层的调用关系，虽看不到函数名，但这不影响技术本身。
　　首先看了一下相关同学的修改，好像C#代码并没有特别大的可能崩溃风险，那么可能修改没用，于是我打开IDA进行0x00000000045eec7c附近反汇编。
　　0x00000000045eec7c此处汇编比较简单（已打码屏掉相关业务名称），x8应该是定值，不可能出错，只有X26寄存器可能出错，打开寄存器
　　从图上可以看出X8刚好是0x21150，符合条件；X26为0x0537053605350534，一看就是诡异不对的值；且从x24到x28都是0x05xx，这不是前面我们2.4小节的一个推论，这是巧合吗？
　　我再向上看看IDA：本函数X26在崩溃点前面有访问，且本函数汇编直接改动X26可能点比较少，我都排除了，说明前面是正常访问的；略加观察又发现三条推论符合2.4小节中：手动剔除某些案例LR寄存器最高16bit，得到0x0742ab04bb8-0x7426516000 = 45EEBB8，这个45EEBB8地址就是在本函数中，这两个基本就是一个问题2.2小节中：我们得出一个重要结论，无栈崩溃就是函数返回ret指令修改，结合本例有栈崩溃前面能正常访问X26，且自己不会直接修改，后面不能访问，也只能是函数调用返回发生，巧合吧，这点在下面会细说2.3小节中：函数栈内存为240H或30H，本函数栈内存大小就是240H，巧合吧
　　总之多么巧合啊,嘿嘿！
　　话又说回来，这个有栈的问题，只看C#业务代码，很难修的。我们继续分析那里改坏寄存器的。3.2 缩小汇编范围，加速分析分析汇编范围
　　如上文所述，动用我们2.4推论得到il2cpp的地址，可以直接定位出问题函数（lr地址需要-4），再验证跳转函数真正内容就可以了，这样有点变态。我们看怎么常规修复这个x26问题，展开更多汇编。
　　如上图所示，在红框标注的X26之间出了问题，这里面有很多行汇编指令。
　　先说一下：本函数C#源码有250行，转成C++源码有976行，由C++生成的汇编有1738行指令，看起来会很痛苦，我们要多结合C++源码与BL这种跳转指令及调用关系链，不要全部反汇编，浪费时间，也没必要。
　　就算这样，我们卡了两个X26之间汇编，确定它们是顺序调用的，但里面涉及函数还是太多，且存在函数嵌套调用其他函数，用人工一个一个排除太费劲，另外还有形如虚函数，BLR Xn调用，这种我们是不知道函数名称的，对应C++源码是这样的，是无法读出来的，都需要我们结合C++及C#代码一点点推断。
　　缩小汇编范围
　　由前面信息，我敢肯定，肯定有更早一点的崩溃，毕竟我们的是幽灵模式，各种情况都有，只要我们广泛搜CrashSight后台就可以了。
　　在CrashSight后台，通过对栈关键字搜索（函数名称），以及对最最近上报的观察，处理一下，我得到下面的信息//XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A实际为本函数函数名称，为了信息安全，我这里代替示意  pc 00000000045eec7c XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 00000000045eecdc XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 00000000045eec84 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 00000000045eebb8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 00000000045eecf4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A 具体CrashSight链接：xxxxxxxx(公开版隐藏)  lr 00000000045eecfc XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A 具体CrashSight链接：xxxxxxxx(公开版隐藏)
　　针对每个崩溃点，我都去IDA看一眼，就是不同对应越界不同的寄存器，越界值刚好是一个不可访问的，不再截图示意。找PC最小的，直接将范围缩小到了00000000045eebb8，这是非常重要的结论，直接命中我们2.4小节漏网之鱼推论：0x0742ab04bb8-0x7426516000 = 45EEBB8，即将秒杀，哈哈。
　　对于最后一个lr 00000000045eecfc，多说一句，如果blr Xn，这个寄存器Xn刚好是0，CrashSight的回溯是这样，只显示下一条的LR值。
　　打开IDA,跳转过去，
　　再看看寄存器值，X9是0x1F90，X8是0，符合猜测
　　在看的过程中，我还发现其他规律：//XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B实际为另一个函数函数名称，为了信息安全，我这里也是代替示意 //XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_C,XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_D,XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_E等都是不同的函数名称  pc 00000000045ed190 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 000000000085b41c XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_E // 实际为上面的变种，比XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B多了一层栈，其具体栈如下 1 pc 000000000085b41c XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_E [arm64-v8a] 2 pc 00000000045ed1a8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B [arm64-v8a] 3 libil2cpp.so pc 000000000463c1a0 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_C 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 000000000463c1b4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_C // 比XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B少一层栈 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 000000000463c1a4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_C // 比XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B少一层栈 具体CrashSight链接：xxxxxxxx(公开版隐藏)  pc 0000000004ed9a20 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_D // 比XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B少二层栈 具体CrashSight链接：xxxxxxxx(公开版隐藏)
　　用IDA看一下XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B这个函数，崩溃点也和XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A没有实质区别，都是高位寄存器坏了，只是这个函数短很多，访问高位寄存器地方少，所以排名不是那么高而已。我们又有下面推论：2.4小节中：手动剔除最高16bit，得到7302d9a190-72fe7ad000 = 45ED190，这个45ED190地址就是在XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_B中，这不巧了！！！同上面XXXXXXXXXXXXXXXXXXXXXXXXXXXXX_A函数，这些都是对应高寄存器非法，又是函数返回ret指令修改，无栈崩溃也是，这不巧了2.3小节中：函数栈内存为240H或30H，本函数栈内存大小就是30H，两个都得到验证，哈哈2.4小节中：越界写坏不是本层函数，更高层次的函数栈，那么可能导致更高层函数崩溃，这不巧了，刚好符合，还引申一个下层栈也可能因收到错误信息而崩溃
　　总结：本小节基本上把我们的汇编级推论验证完了，如果我们用汇编级去秒杀，可以更快。到这里本案例基本上80%的内容被搞定了，也说明验证了至少发现了两个A，B函数。接下来从汇编角度来进一步分析，他们都是虚函数，我们只需分析出这个虚函数到底是谁即可。3.3 揪出真凶，分析幽灵一样的原因
　　从45EEBB8看，实际这是LR值，需退一条汇编指令，就是红框，虚函数调用。
　　结合汇编上下文，C++源码上下文，C#源码，很容易推出X9就是XXXXXXXXXXXXXXXX_M函数地址，在IDA我已经标注；再汇编跳转过去
　　看到汇编开头我就笑了，基本就是他了，居然把高位寄存器保存了一遍，还有0x70字节大小栈对象，为可以越界埋下伏笔，这里汇编不用看了（当然我自己为了实锤，还是会看)，只需要看高级语言就行了。
　　我们直接看C#代码,由于业务比较长，也存在多处可能越界点情况，我略去很多没用的代码，作一段伪码：protected override void XXXXXXXXXXXXXXXX_M(bool bIn) {     AAAA AInfo = new AAAA();     AInfo.Count = 0;      for (int i = 0; i < TestCount; i++)     {         unsafe         {             AInfo.Data[AInfo.Count++] = OriginData[i];         }     } }
　　C#代码虽然是new，但结构体AAAA对象AInfo是栈对象，并非在堆区，这里在C#生成的C++代码及汇编都可以确认，我就不在贴更低层次的代码。它是unsafe的，看了一下改动，由于逻辑改动，确实导致可能数组不足，存在越界。但这里看起来像是连续的写入，越界为什么那么幽灵呢？？？
　　回答这个问题之前，还要看AAAA结构[StructLayout(LayoutKind.Explicit, Pack = 8, Size = 82)] unsafe public struct AAAA {     [FieldOffset(0)] public fixed ushort Data[40];     [FieldOffset(80)] public byte Count; }
　　OH,OH,OH!!! 明白了
　　原来AInfo.Count是在数组AInfo.Data后面哇，栈越界先覆写AInfo.Count自己；然后for循环再次推动越界时，由于是AInfo.Count是byte型，是否再次越界取决于写入的值。数组大小为40，如果写入的AInfo.Count为30，就不越界，反而覆盖了原来的值；如果为42，就越界，开始破坏x28，以此类推；如果为100，就可能破坏更加上层的函数栈。加上逻辑层本身for循环次数TestCount由业务决定，也是不定的，AInfo.Count写入值更是不定，多层不定折腾下，是否越界就变得很玄学。越界了从哪里开始越也很玄，越多少字节也很玄。只有明确越界覆写是ushort，也就是16位。
　　到此所有问题得解，一切结束。四: 总结与反思
　　我们现在站在事后诸葛亮角度去分析：C++这种函数栈越界很好处理，编译器开启函数栈保护，只需牺牲一点性能，就可以搞定，是否平时尝试开启一下？项目是否能接入更高级的内存诊断工具，Google ASan，anitation， fuzzing！能否开启CrashSight的简易内存dump墓碑文件能够推进Crash修复需要近乎完全确认才能声明修复了，否则可能误导
　　本文较长，可能技术点有错误或者不全面，欢迎指出与讨论。如果大家有更好方法，一起交流讨论。相比Google平台，感谢CrashSight平台提供寄存器，模块地址，日志等信息供追查。