[转]Show Stopper 一次 crash 调试的夺命狂奔

这几天一直在忙着调试 crash 的问题。周末两天都在加班。 周日更是从早上8：00 到晚上 12：50 一直没离开过办公室. 加上这个项目对我们整个开发组以及 EM 都很重要，不容有失，这不禁让我想起了微软 NT 开发组开发 NT 的情形，所以有了这个标题.



这次是在 android 上，但不是 arm，而是 x86 atom。我们的程序是从 windows 上移植到 android 上的, 一个 C++ 写的底层库作为 service，UI 是 java 写的。 因为是在 android 2.2 上，java 也是唯一的写 UI 的选择。 java 通过 aidl/jni 与底层 service/c++ 代码交互。这样的架构让调试很悲剧。



之前一直抱怨 xcode 调试多么不给力，而现在在 android 上的调试已经原始到通过 log 分析程序的执行。arm 上的调试还能用 gdb 勉强为之，而 x86 下那简直就是坑爹。好不容易把符号神马的搞定，gdb 远程调试到设备上，却发现程序不 crash 了。



logcat 和 tombstone 显示的 crash 调用栈是这样的：

06370 INF/DEBUG   ( 1670): signal 11 (SIGSEGV), fault addr deadbaad
06371 INF/DEBUG   ( 1670):  eax 00000000  ebx 801614f4  ecx 00000004  edx 00001000
06372 INF/DEBUG   ( 1670):  esi b3afa000  edi bfca7b18
06373 INF/DEBUG   ( 1670):  xcs 00000073  xds 0000007b  xes 0000007b  xfs 00000000 xss 0000007b
06374 INF/DEBUG   ( 1670):  eip 8011c768  ebp bfca7b28  esp bfca7af0  flags 00010286
06375 INF/DEBUG   ( 1670): #00
06376 INF/DEBUG   ( 1670):     eip: 8011c768  /system/lib/libc.so (abort)
06377 INF/DEBUG   ( 1670): #01
06378 INF/DEBUG   ( 1670):     eip: 8010ed4b  /system/lib/libc.so (dlfree)
06379 INF/DEBUG   ( 1670): #02
06380 INF/DEBUG   ( 1670):     eip: 80111503  /system/lib/libc.so (free)
06381 INF/DEBUG   ( 1670): #03
06382 INF/DEBUG   ( 1670):     eip: 80200a1d  /system/lib/libstdc++.so (_ZdlPv)
06383 INF/DEBUG   ( 1670): #04
06384 INF/DEBUG   ( 1670):     eip: 86138519  /data/data/cip.impservice/lib/libimpjni2.so (_ZSt12__stl_deletePv)
06385 INF/DEBUG   ( 1670): #05
06386 INF/DEBUG   ( 1670):     eip: 8613853d  /data/data/cip.impservice/lib/libimpjni2.so (_ZNSt11__new_alloc10deallocateEPvj)
06387 INF/DEBUG   ( 1670): #06
06388 INF/DEBUG   ( 1670):     eip: 8613856e  /data/data/cip.impservice/lib/libimpjni2.so (_ZNSaIcE10deallocateEPcj)
06389 INF/DEBUG   ( 1670): #07
06390 INF/DEBUG   ( 1670):     eip: 861385b1  /data/data/cip.impservice/lib/libimpjni2.so (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06391 INF/DEBUG   ( 1670): stack:
06392 INF/DEBUG   ( 1670): #00
06393 INF/DEBUG   ( 1670):     bfca7af0  00000002   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06394 INF/DEBUG   ( 1670):     bfca7af4  bfca7b18  [stack] (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06395 INF/DEBUG   ( 1670):     bfca7af8  00000000   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06396 INF/DEBUG   ( 1670):     bfca7afc  00000000   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06397 INF/DEBUG   ( 1670):     bfca7b00  00000000   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06398 INF/DEBUG   ( 1670):     bfca7b04  00000000   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06399 INF/DEBUG   ( 1670):     bfca7b08  84a60900  /system/lib/libstlport.so (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06400 INF/DEBUG   ( 1670):     bfca7b0c  00000010   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06401 INF/DEBUG   ( 1670):     bfca7b10  0a1f8300  [heap] (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06402 INF/DEBUG   ( 1670):     bfca7b14  00000001   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06403 INF/DEBUG   ( 1670):     bfca7b18  fffffbdf   (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06404 INF/DEBUG   ( 1670):     bfca7b1c  801614f4  /system/lib/libc.so (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06405 INF/DEBUG   ( 1670):     bfca7b20  0a1f6c98  [heap] (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06406 INF/DEBUG   ( 1670):     bfca7b24  bfca8410  [stack] (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06407 INF/DEBUG   ( 1670):     bfca7b28  bfca7b68  [stack] (_ZNSt4priv17_STLP_alloc_proxyIPccSaIcEE10deallocateES1_j)
06408 INF/DEBUG   ( 1670): #01
06409 INF/DEBUG   ( 1670):     bfca7b2c  8010ed4b  /system/lib/libc.so (dlfree)
06410 INF/DEBUG   ( 1670):     bfca7b30  80163118   (dlfree)
06411 INF/DEBUG   ( 1670):     bfca7b34  00000000   (dlfree)
06412 INF/DEBUG   ( 1670):     bfca7b38  8010f3ab  /system/lib/libc.so (dlmalloc)
06413 INF/DEBUG   ( 1670):     bfca7b3c  801614f4  /system/lib/libc.so (dlmalloc)
06414 INF/DEBUG   ( 1670):     bfca7b40  00000066   (dlmalloc)
06415 INF/DEBUG   ( 1670):     bfca7b44  bfca8410  [stack] (dlmalloc)
06416 INF/DEBUG   ( 1670):     bfca7b48  0a1f6c90  [heap] (dlmalloc)
06417 INF/DEBUG   ( 1670):     bfca7b4c  801114d2  /system/lib/libc.so (malloc)
06418 INF/DEBUG   ( 1670):     bfca7b50  0000002f   (malloc)
06419 INF/DEBUG   ( 1670):     bfca7b54  80201d98  /system/lib/libstdc++.so
06420 INF/DEBUG   ( 1670):     bfca7b58  bfca7b68  [stack]
06421 INF/DEBUG   ( 1670):     bfca7b5c  801614f4  /system/lib/libc.so
06422 INF/DEBUG   ( 1670):     bfca7b60  0a1f6caf  [heap]
06423 INF/DEBUG   ( 1670):     bfca7b64  bfca8410  [stack]
06424 INF/DEBUG   ( 1670):     bfca7b68  bfca7b78  [stack]
06425 INF/DEBUG   ( 1670):     ......  ......


每次都几乎看不到我们的代码，好不容易看到一个用户代码的地址，通过 addr2line, 也是 STL 里的 _alloc.h 之类。这其实是一个提示，但一开始我们并没有在意。我们还是坚忍的打着 log，试图逐一的排查 crash， 好不容易向前推进了一些让程序跑得更远一点，再跑一次却发现又回到了起点， crash 又在前面的代码中出现鸟，我勒个去～



不稳定的 crash 让我有些沮丧，同时也让我产生了怀疑，这到底是不是我们的代码的问题？ 看看每次 crash 的调用栈，都有 STL 牵涉其中，又联想起我们用的 stlport 不是线程安全的 (编译时使用了 _NOTHREADS 宏）,  是不是应该去掉 _NOTHREADS 编译试试？ 但遇到的新问题是，我们使用的动态链接的系统自带的 STL，虽然可以替换掉系统的，但势必影响其他的程序。这是不能接受的。 马上想到我们可以编译一个静态库，连接到我们的程序中。说干就干，拿到 stlport 的代码，折腾一番，也就编译好了。这里还有一个小插曲， android 的头文件说它对 #include_next 支持的并不好，但最终我们还是用了 gcc 的这个 feature 才让代码编译通过。



但测试的结果却让人沮丧，我再次确认了的确是链接到了自己编译的静态版本，悲催的发现这次尝试可耻的失败鸟～ 这时已是周一凌晨 0:50 了，而我已经在办公室呆了 16个小时没有离开。



周一早上9:40到达公司。一计不成，又生一计，这次我注意到调用栈顶端的 lib 的 free 函数，既然每次都 crash 在这里，那我能不能让它不调用这个函数。联想起之前看过的 stlport 文档 (http://www.stlport.com/doc/configure.html)，的确有一个宏  _STLP_USE_NEWALLOC 可以让 stlport 使用 new/delete 而不是 malloc/free 来分配/释放内存, 无独有偶，目前我们做的这个项目的前身（另一个项目组开发的）编译的时候就加了 stlport 的这个宏（我们在移植代码的时候由于匆忙，急于让代码通过编译，没能加上这个宏），这更坚定了我做这个尝试的决心。于是给十几个模块的 mk 文件都加上了这几个 stlport 相关的宏(看 stlport 文档关于分配内存的宏），rebuild all。 哈利露亚～ 幸福来得那么突然， 程序真的跑起来了，不再 crash！



总结这次调试的经验教训:

1. 开始时调试进展缓慢，问题出在编译/调试环境很不给力。

我们需要把代码放到另一个 site 的唯一的 build machine 上让同事帮忙编译，这个过程让调试过程变得很漫长。 所以我让同事给我在 build machine 上单独弄了一个环境，这样我就可以随意的修改/调试代码了

2. 对问题不敏感，虽然每次都看到 stl/free 出现在调用栈中，直到在错误的方向上迷失才意识到我们可能走错路了

3. 对项目本身不够了解，我没能意识到我们其实有一个能用的版本（虽然我们重构了很多），的确应该早些查看别人是怎么做到的。 这里有一个客观原因是我之前一直不在这个项目。

4. Android 的调试环境太坑爹了。既然符号神马的都齐活了，在调研栈里却只显示地址和莫名其妙的函数名（还是 decorated), 尼玛就不能把代码行也加进去啊！有木有！Android 开发小组在忙于追赶/超越苹果的时候，明显对开发者照顾不够。 当然，也有可能是我被微软给惯坏了.

注：本人转自http://nick.luckygarden.org/?p=454