怎樣分析crash dump(記憶體錯誤)1.Crash> Kmem -s2.CONFIG_DEBUG_SLAB3.log | tail xxx4.Crash> kmem -S cache name

轉載自：http://www.itdaan.com/blog/2014/09/15/b143a196377b.html

Memory錯誤

在核心中，記憶體是以cache的形式組織的，每個對象類型對應一個cache，如（inod_cache,dentry_cache, buffer_head,vm_area_strutct等）；每個cache包含多個slab(slab由一個或多個頁組成，這些頁實體上是連續的)；每個slab包含多個初始化的對象。

Cache可以分為兩類【kmalloc使用的和其他】，當然他們是用同一個函數建立的。

1.Crash> Kmem -s

CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE

ee2bb0c0  scsi_sense_cache 120 2 32 1 4k

ee2bbac0 scsi_cmd_cache 176 2 22 1 4k

ee000c60 size-4194304 4194304 0 0 0 4096k

ee000bc0 size-2097152 2097152 0 0 0 2048k

ee000b20 size-1048576 1048576 1 1 1 1024k

ee000a80 size-524288 524288 0 0 0 512k

ee0009e0 size-262144 262144 0 0 0 256k

ee000940 size-131072 131072 1 1 1 128k

ee0008a0 size-65536 65536 2 2 2 64k

ee000800 size-32768 32768 1 1 1 32k

ee000760 size-16384 16384 9 9 9 16k

ee0006c0 size-8192 8192 10 10 10 8k

ee000620 size-4096 4096 26 44 44 4k

ee000580 size-2048 2072 53 60 20 8k

ee0004e0 size-1024 1048 332 343 49 8k

ee000440 size-512 536 771 798 114 4k

ee0003a0 size-256 280 54 84 6 4k

ee000300 size-192 216 734 756 42 4k

ee000260 size-128 152 2301 2314 89 4k

ee0001c0 size-32 56 13439 13668 204 4k

ee000120 size-96 120 1067 1120 35 4k

ee000080 size-64 88 3137 3168 72 4k

調用函數kmalloc(xxx)得到的memory都來名字為size-xx的cache.

2.CONFIG_DEBUG_SLAB

為便于調試，在每個對象可以添加SLAB_RED_ZONE，添加這塊記憶體的最後使用者SLAB_STORE_USER，且用SLAB_POISON初始化對象。

這些特殊的元素是什麼？

Include/linux/poison.h

#define RED_INACTIVE 0x09F911029D74E35BULL

#define RED_ACTIVE 0xD84156C5635688C0ULL

#define POISON_INUSE 0x5a

#definePOISON_FREE 0x6b

#define POISON_END 0xa5

3.log | tail xxx

當slab出錯時，會把cachename/ objecet的開始位址(沒有考慮redzone)

redzone的内容/lastuser和object的内容都會列印出來，另外還包含該對象前後對象的資訊。

[ 45.501503:0] Slab corruption (Not tainted): size-64 start=e74b3398,len=64

[ 45.508518:0] Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.

[ 45.514118:0] Last user: [<c03446e8>](__DWC_FREE+0x1c/0x20)

[ 45.519816:0] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b d8 b0 54 e8 kkkkkkkkkkkk..T.

[ 45.527633:0] Prev obj: start=e74b3340, len=64

[ 45.532108:0] Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.

[ 45.537880:0] Last user:[<c045ad78>](binder_get_ref_for_node+0x6c/0x204)

[ 45.544777:0] 000: 47 34 00 00 2c 8b e5 e7 00 00 00 00 00 00 00 00 G4..,...........

[ 45.552584:0] 010: f1 31 4b e7 50 83 e5 e7 10 46 61 e7 00 00 00 00 .1K.P....Fa.....

[ 45.560393:0] Next obj: start=e74b33f0, len=64

[ 45.564866:0] Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.

[ 45.570636:0] Last user: [<c004df30>](copy_creds+0x108/0x1e4)

[ 45.576479:0] 000: 01 00 00 00 5a 5a 5a 5a 00 00 00 00 5a 5a 5a 5a ....ZZZZ....ZZZZ

[ 45.584281:0] 010: ad 4e ad de ff ff ff ff ff ff ff ff 00 00 00 00 .N..............

[ 45.592154:0] ------------[ cut here ]------------

[ 45.596974:0] kernel BUG atmm/slab.c:2037!

[ 45.601188:0] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM

[ 45.607223:0] Modules linked in:

[ 45.610516:0] CPU: 0 Not tainted (3.4.0-gc37fe8c-dirty #657)

[ 45.616585:0] PC is at check_poison_obj+0x194/0x1b4

[ 45.621512:0] LR is at console_unlock+0x1c0/0x1d4

[ 45.626260:0] pc : [<c00d46f8>] lr : [<c0028fe0>] psr: 60000093

[ 45.626294:0] sp : e58e1c68 ip : e58e1a40 fp : e58e1c9c

[ 45.638134:0] r10: e74b3398 r9 : 00000008 r8 : e74b3338

[ 45.643565:0] r7 : 00000040 r6 : e74b3000 r5 : e74b33e8 r4 :ee000080

[ 45.650296:0] r3 : 00000001 r2 : 00000010 r1 : 00000020 r0 :e74b33f0

[ 45.657033:0] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel

[ 45.664635:0] Control: 10c53c7d Table: af4e404a DAC: 00000015

kmem-S size-64

從列印的資訊siize-64start=e74b3398, 得知出問題的是cache:size-64,位址為

e74b3390.

4.Crash> kmem -S cache name

crash>kmem -S size-64 | grep e74b3390

[e74b3390]

crash>rd e74b3390 0x64

e74b3390: 9d74e35b 09f91102 6b6b6b6b6b6b6b6b [.t.....kkkkkkkk

e74b33a0: 6b6b6b6b 6b6b6b6b 6b6b6b6b 6b6b6b6b kkkkkkkkkkkkkkkk

e74b33b0: 6b6b6b6b e854b0d8 6b6b6b6b6b6b6b6b kkkk..T.kkkkkkkk

e74b33c0: 6b6b6b6b 6b6b6b6b 6b6b6b6b 6b6b6b6b kkkkkkkkkkkkkkkk

e74b33d0: 6b6b6b6b a56b6b6b 9d74e35b09f91102 kkkkkkk.[.t.....

e74b33e0: ff000000 c03446e8

從出問題的這個object的用于debug的資訊可知：

redzone: 9d74e35b 09f91102 :RED_INACTIVE

poisondata: 6b : POISON_FREE

usercall : c03446e8

5.last caller

最後操作這塊記憶體的函數為：

crash>dis -r c03446e8

0xc03446cc<__DWC_FREE>: mov r12, sp

0xc03446d0<__DWC_FREE+4>: push {r11, r12, lr, pc}

0xc03446d4<__DWC_FREE+8>: sub r11, r12, #4

0xc03446d8<__DWC_FREE+12>: stmfd sp!, {lr}

0xc03446dc<__DWC_FREE+16>: ldmfd sp!, {lr}

0xc03446e0<__DWC_FREE+20>: mov r0, r1

0xc03446e4<__DWC_FREE+24>: bl 0xc00d51fc <kfree>

0xc03446e8<__DWC_FREE+28>: ldm sp, {r11, sp, pc}

結合如下的backtrace，可知問題就是從slab申請的一個對象，但發現其中的元素不對(不是0x6b,卻出現了e854b0d8，是以crash)

[ 45.596974:0] kernel BUG at mm/slab.c:2037!

[ 46.736498:0] Backtrace:

[ 46.739243:0] [<c00d4564>] (check_poison_obj+0x0/0x1b4) from[<c00d4f84>] (cache_alloc_debugcheck_after+0x3c/0x1a0)

[ 46.749743:0] [<c00d4f48>](cache_alloc_debugcheck_after+0x0/0x1a0) from [<c00d6df0>](__kmalloc+0x140/0x234)

[ 46.759680:0] r7:00000038 r6:00008020 r5:a0000093 r4:ee000080

[ 46.765709:0] [<c00d6cb0>] (__kmalloc+0x0/0x234) from[<c03448c0>] (__DWC_ALLOC_ATOMIC+0x20/0x24)

[ 46.774674:0] [<c03448a0>] (__DWC_ALLOC_ATOMIC+0x0/0x24) from[<c0340dbc>] (dwc_otg_hcd_urb_alloc+0x30/0x40)

[ 46.784585:0] [<c0340d8c>] (dwc_otg_hcd_urb_alloc+0x0/0x40)from [<c0352f00>] (urb_enqueue+0xf0/0x258)

[ 46.793916:0] r4:db95faa8 r3:00000003

[ 46.797796:0] [<c0352e10>] (urb_enqueue+0x0/0x258) from[<c031f32c>] (usb_hcd_submit_urb+0x5c4/0x6a4)

[ 46.807069:0] [<c031ed68>] (usb_hcd_submit_urb+0x0/0x6a4) from[<c031fa60>] (usb_submit_urb+0x2a0/0x2bc)

[ 46.816603:0] [<c031f7c0>] (usb_submit_urb+0x0/0x2bc) from[<c03208bc>] (usb_sg_wait+0x4c/0x138)

6.解決問題

從上面的分析可知，問題是memoryfree後，代碼又操作了這塊記憶體。

現在問題是__DWC_FREE最後操作了這塊記憶體，__DWC_FREE隻是封裝了kfree,

如果直接使用kfree,通過SLAB_STORE_USER就可以知道那個函數調用了kfree,

進而知道申請的對象類型，看那個該對象類型的那個成員被指派，就可以在代碼中搜尋。

如該例知道了類型為dwc_otg_qtd_t，且成員qh在記憶體釋放後被指派，就可以在代碼中詳細查找，分析。

crash>dwc_otg_qtd_t e74b3398

structdwc_otg_qtd_t {

data_toggle= 0x6b,

control_phase= (DWC_OTG_CONTROL_DATA | DWC_OTG_CONTROL_STATUS | unknown:1802201960),

complete_split= 0x6b,

ssplit_out_xfer_count= 0x6b6b6b6b,

error_count= 0x6b,

isoc_frame_index= 0x6b6b,

isoc_split_pos= 0x6b,

isoc_split_offset= 0x6b6b,

urb= 0x6b6b6b6b,

qh= 0xe854b0d8,

qtd_list_entry= {

cqe_next= 0x6b6b6b6b,

cqe_prev= 0x6b6b6b6b

},

in_process= 0x6b,

n_desc= 0x6b,

isoc_frame_index_last= 0x6b6b

}

在相關的代碼中搜尋哪裡操作了資料結構dwc_otg_qtd_t的qh成員。