System Crash实例分析一

死机分析以前在R平台搞过，基本就是抓到死机时的CPU register等信息，然后用objdump反汇编出来结合源码定位分析，现在到了手机平台，多了个Tracer32，高通分析死机都在用，现在死机都挂我这了，老问高通也不是个事重拾下，我觉得可以不用trace32，基本还是那老一套。

先来看死机现场:

[ 1256.852648] Unable to handle kernel NULL pointer dereference at virtual address 00000004 
[ 1256.931061] pgd = e2110000 
[ 1256.933725] [00000004] *pgd=00000000 
[ 1256.937725] Internal error: Oops: 5 [#1] PREEMPT SMP ARM 
[ 1256.942470] Modules linked in: wlan(O) [last unloaded: wlan] 
[ 1256.948098] CPU: 1 PID: 585 Comm: qti Tainted: G W O 3.18.71-perf-g24d2c84 #1 
[ 1256.956092] task: e41161c0 ti: e2148000 task.ti: e2148000 
[ 1256.961479] PC is at diagchar_read+0x610/0x11fc 
[ 1256.965978] LR is at 0x0 
[ 1256.968488] pc : [<c04e0b24>] lr : [<00000000>] psr: 60010013 
[ 1256.968488] sp : e2149ef0 ip : 00000051 fp : b1bb5b7c 
[ 1256.979944] r10: c6651000 r9 : 00000201 r8 : c5227bc0 
[ 1256.985152] r7 : c13dbc38 r6 : 00000014 r5 : 000186a0 r4 : b1bb5b78 
[ 1256.991676] r3 : 00000000 r2 : 80000000 r1 : 00000000 r0 : 00000000 

内核空指针，一个关键信息是pc：c04e0b24。

objdump vmlinux出来后，基本-lD就够用了，搜到pc:

/code/kernel/msm-3.18/drivers/char/diag/diagchar_core.c:2933
c04e0b1c:    e3510000     cmp     r1, #0
c04e0b20:    05983030     ldreq      r3, [r8, #48]    ; 0x30
c04e0b24:    05933004     ldreq     r3, [r3, #4] ===============> 这里crash
c04e0b28:    0a000028     beq     c04e0bd0 <diagchar_read+0x6bc>
c04e0b2c:    ea0001b2     b     c04e11fc <diagchar_read+0xce8> 
/code/kernel/msm-3.18/drivers/char/diag/diagchar_core.c:2937

找到源码2933行:

    if (driver->data_ready[index] & EVENT_MASKS_TYPE) {
        /*Copy the type of data being passed*/
        data_type = driver->data_ready[index] & EVENT_MASKS_TYPE;
        session_info = diag_md_session_get_peripheral(APPS_DATA);
        COPY_USER_SPACE_OR_EXIT(buf, data_type, 4);
2931        if (session_info && session_info->event_mask &&
2932            session_info->event_mask->ptr) {
2933            COPY_USER_SPACE_OR_EXIT(buf + sizeof(int),
                    *(session_info->event_mask->ptr),
                    session_info->event_mask->mask_len);
        } else {
            COPY_USER_SPACE_OR_EXIT(buf + sizeof(int),
                        *(event_mask.ptr),
                        event_mask.mask_len);
        }
        driver->data_ready[index] ^= EVENT_MASKS_TYPE;
        goto exit;
    }

2933行是：COPY_USER_SPACE_OR_EXIT(buf + sizeof(int),，crash的地方再看下现场：

r8 : c5227bc0
r3 : 00000000

也就是说r3 = 0是触发这个死机的因, r3和r8看着应该和2934，2935有关，那到底是不是了，先看下偏移，struct里又是宏又是嵌套结构体，用gdb帮忙：

$ arm-eabi-gdb vmlinux 
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.

(gdb) p &((struct diag_md_session_t*)0)->event_mask
$1 = (struct diag_mask_info **) 0x30

(gdb) p &((struct diag_mask_info*)0)->mask_len
$2 = (int *) 0x4 <__vectors_start+4>

再往上看看就能得出：

r8=session_info
r3=r8+48=session_info->event_mask
r3=r3+4=session_info->event_mask->mask_len

r3=0触发，也就是session_info->event_mask是0？2931已经判断过了：

/code/kernel/msm-3.18/drivers/char/diag/diagchar_core.c:2931 (discriminator 1)
c04e0a68:    e3580000     cmp    r8, #0 ==================> r8 = sesstion_info
/work/buildfarm/jenkins/workspace/buildfarml_rmnj_10/kernel/msm-3.18/drivers/char/diag/diagchar_core.c:2930 (discriminator 1)
c04e0a6c:    e2833004     add    r3, r3, #4
c04e0a70:    e58d3024     str    r3, [sp, #36]    ; 0x24
/code/kernel/msm-3.18/drivers/char/diag/diagchar_core.c:2931 (discriminator 1)
c04e0a74:    0a00002d     beq    c04e0b30 <diagchar_read+0x61c>
c04e0a78:    e5982030     ldr    r2, [r8, #48]    ; 0x30 =====> r2 = sesstion_info->event_mask
c04e0a7c:    e3520000     cmp    r2, #0 ==============> sesstion_info->event_mask == 0?
c04e0a80:    0a00002a     beq    c04e0b30 <diagchar_read+0x61c>
/code/kernel/msm-3.18/drivers/char/diag/diagchar_core.c:2932 (discriminator 1)
c04e0a84:    e592a000     ldr    sl, [r2]
/code/kernel/msm-3.18/drivers/char/diag/diagchar_core.c:2931 (discriminator 1)
c04e0a88:    e35a0000     cmp    sl, #0
c04e0a8c:    0a000027     beq    c04e0b30 <diagchar_read+0x61c>

so, 难道是DDR出现了跳变？多半是硬件问题。