"stack corruption detected"问题探究

问题现象

复现步骤
- Android 7.0平台
- 安装手机百度apk(v8.6.5)
- 启动App后必现native crash

分析定位

初步分析

tombstone文件如下

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Native Crash TIME: 959207
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Revision: '0'
ABI: 'arm' 
pid: 3329, tid: 3719, name: bner  >>> com.baidu.searchbox <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'stack corruption detected'
    r0 00000000  r1 00000e87  r2 00000006  r3 00000008
    r4 84cff978  r5 00000006  r6 84cff920  r7 0000010c
    r8 84cfe708  r9 923fc200  sl 00000000  fp 84cfe694
    ip 0000000d  sp 84cfe530  lr ae08c597  pc ae08edf4  cpsr 000b0010
    d0  0000000000000000  d1  0000000000000000
    d2  0000000000000000  d3  0000000000000000
    d4  0000000000000000  d5  0000000000000000
    d6  0000000000000000  d7  0000000000000000
    d8  0000000000000000  d9  0000000000000000
    d10 0000000000000000  d11 0000000000000000
    d12 0000000000000000  d13 0000000000000000
    d14 0000000000000000  d15 0000000000000000
    d16 005f006b006e0075  d17 003000310033006b
    d18 0000000000052da0  d19 000000000004a938
    d20 000000002000166a  d21 00013093a834e468
    d22 0000000000000000  d23 0000000000000000
    d24 0000004100000052  d25 ffffff79ffffffbb
    d26 0000000000000000  d27 0000000000000000
    d28 0000000000000000  d29 0000000000000000
    d30 0000000000000000  d31 00000000000e8800
    scr 88000093

backtrace:
    #00 pc 00049df4  /system/lib/libc.so (tgkill+12)
    #01 pc 00047593  /system/lib/libc.so (pthread_kill+34)
    #02 pc 0001d855  /system/lib/libc.so (raise+10)
    #03 pc 000193a1  /system/lib/libc.so (__libc_android_abort+34)
    #04 pc 00017014  /system/lib/libc.so (abort+4)
    #05 pc 0001b84f  /system/lib/libc.so (__libc_fatal+22)
    #06 pc 000482ab  /system/lib/libc.so (__stack_chk_fail+6)
    #07 pc 00002c29  /data/app/com.baidu.searchbox-1/lib/arm/libbner.so (getSec+96)
    #08 pc 0000142f  /data/app/com.baidu.searchbox-1/lib/arm/libbner.so (Java_com_bnerclient_InitSo_getSec+2)
    #09 pc 01623e41  /data/app/com.baidu.searchbox-1/oat/arm/base.odex (offset 0x153f000)

对比实验

Nexus 5x/6p(Android 7.0)上无法复现
我司多个产品均能复现
有一台机器(烧录的本地pc编译版本)无法复现

侧面排查

另一同事，通过对比Jenkins编译版本和我本地编译版本的多个文件，发现/system/build.prop中的ro.build.host属性值存在差异，修改该属性值后问题不再复现。

正面分析

原理

stack check failed的根本原因在于栈内存被覆盖，编译器会在函数进入和退出前后插入一个stack check的东西用于检测内存越界这种错误。

汇编分析

进入函数时ldr/str

00002bc8 :
2bc8:       b5f0            push    {r4, r5, r6, r7, lr}
2bca:       4d19            ldr     r5, [pc, #100]  ; (2c30 )
2bcc:       b091            sub     sp, #68 ; 0x44
2bce:       1c04            adds    r4, r0, #0
2bd0:       447d            add     r5, pc
2bd2:       682d            ldr     r5, [r5, #0]
2bd4:       ae02            add     r6, sp, #8
2bd6:       9201            str     r2, [sp, #4]
2bd8:       682b            ldr     r3, [r5, #0]
2bda:       2100            movs    r1, #0
2bdc:       2232            movs    r2, #50 ; 0x32
2bde:       1c30            adds    r0, r6, #0
2be0:       930f            str     r3, [sp, #60]   ; 0x3c ==> store到[sp + 60]

退出函数前检查栈内存是否相同

... ...
2c20:       9a0f            ldr     r2, [sp, #60]   ; 0x3c ==>从[sp + 60] load
2c22:       682b            ldr     r3, [r5, #0]     
2c24:       429a            cmp     r2, r3
2c26:       d001            beq.n   2c2c      相等就正常退出
2c28:       f000 f94a       bl      2ec0    不相等就跳到__stack_chk_fail执行abort
2c2c:       b011            add     sp, #68 ; 0x44
2c2e:       bdf0            pop     {r4, r5, r6, r7, pc}

所以，问题出现后，我们可以查看[sp, #60]附近的内存数据，就能知道大概什么类型的数据发生内存越界。

gdb堆栈和相关寄存器

(gdb) bt
#0  tgkill () at bionic/libc/arch-arm/syscalls/tgkill.S:10
#1  0xae08c596 in pthread_kill (t=, sig=6) at bionic/libc/bionic/pthread_kill.cpp:45
#2  0xae062858 in raise (sig=3719) at bionic/libc/bionic/raise.cpp:34
#3  0xae05e3ce in __libc_android_abort () at bionic/libc/bionic/abort.cpp:57
#4  0xae05c018 in abort () at bionic/libc/arch-arm/bionic/abort_arm.S:43
#5  0xae060852 in __libc_fatal (format=0x0) at bionic/libc/bionic/libc_logging.cpp:678
#6  0xae08d2ae in __stack_chk_fail () at bionic/libc/bionic/__stack_chk_fail.cpp:35
#7  0x9249ec2c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) f 7
(gdb) i r
r0             0x0  0
r1             0xe87    3719
r2             0x6  6
r3             0x8  8
r4             0x84cfe564   2228217188
r5             0x84cfe554   2228217172
r6             0x84cfe5a8   2228217256
r7             0x84839db0   2223218096
r8             0x84cfe708   2228217608
r9             0x923fc200   2453651968
r10            0x0  0
r11            0x84cfe694   2228217492
r12            0xd  13
sp             0x84cfe550   0x84cfe550
lr             0xae05e3cf   -1375345713
pc             0xae05e3ce   0xae05e3ce <__libc_android_abort()+80>
cpsr           0xb0030  720944

查看sp+60附近内存

(gdb) x /32xw 0x84cfe5a0+60
0x84cfe5dc: 0x3031336b 0x3230362f 0x8e3a002f 0x84cfe968
0x84cfe5ec: 0x84cfe708 0x84cfe6c8 0x9249d433 0x74129b00
0x84cfe5fc: 0x975abe43 0x8e3a7cdc 0x00000000 0x00000002
0x84cfe60c: 0x12f9d940 0x740fad60 0x00000000 0x923fc28c
0x84cfe61c: 0x72ce9c55 0x6ff3d9f8 0x00000000 0x00000000
0x84cfe62c: 0x00000000 0x00000000 0x00000000 0x00000000
0x84cfe63c: 0x00000000 0x00000000 0x00000000 0x00000000
0x84cfe64c: 0x00000000 0x00000000 0x00000000 0x00000000

这里很明显是ASCII字符

(gdb) p (const char *)0x84cfe5dc
$1 = 0x84cfe5dc "k310/602/"

再往前查看整个字符串，就能看到这是我司特有的一个URL

(gdb) p (const char *)0x84cfe5a0
$2 = 0x84cfe5a0 "}\315\377\377\020\346τhttp://10.0.1.97:8080/jenkins/job/sprdroid7.0_trunk_k310/602/"

结合汇编code, 猜测这里应是获取某个属性。

现在通过加log, 已确认是App在访问ro.build.host属性导致的。

06-16 10:08:10.869  1956  2288 E libc    : __system_property_get: property name = "ro.build.host"
--------- beginning of crash
06-16 10:08:10.869  1956  2288 F libc    : stack   corruption detected

再查看下出问题手机上的ro.build.host的值, 正好对应上

$adb shell getprop ro.build.host
http://10.0.1.97:8080/jenkins/job/sprdroid7.0_trunk_k310/602/

长度为62

Nexus 6p上该属性的值为

$ adb shell getprop ro.build.host
wphr7.hot.corp.google.com

长度为26

本地编译的版本该属性的值为
```
$ adb shell getprop ro.build.host
tj03456pcu1
```
长度为12
这基本就确定是获取属性值出现越界。

Root Cause

Android定义的属性值最大长度为92。
```
#define PROP_VALUE_MAX  92
```
而手机百度App在栈上用于存储property的局部数组size太小，大概为50+左右。所以遇到超过50+字符串，就容易出现栈内存越界了。

解决方案

此问题在我司平台不解决
反馈此问题至百度客服，希望百度解决App栈内存越界问题。

baidu.JPG