碼上快樂

相關內容    簡體    繁體

crash處理core文件

本文轉載自   查看原文   2017-03-07 11:11   1624 

（一時心血來潮總結的，供大家參考，時間倉促，不足之處勿拍磚，歡迎討論~）
Crash工具用於解析Vmcore文件，Vmcore文件為通過kdump等手段收集的操作系統core dump信息，在不采用壓縮的情況下，其相當於整個物理內存的鏡像，所以其中包括了最全面、最完整的信息，對於分析定位各種疑難問題有極大的幫助。配置kdump后，在內核panic后，會自動進入kump流程，搜集Vmcore。
Crash工具即為專門用於分析vmcore文件的工具，其中提供了大量的實用分析命令，極大的提高了vmcore的分析效率。
在分析vmcore的過程中，常常需要解析內核某個流程中的關鍵變量的值，以便確認故障當時系統的狀態，本文主要介紹變量的解析方法，主要分全局變量和局部變量兩種情況。
1、全局變量解析非常簡單，可通過在crash中直接p <變量名>打印，如：

  1.     crash> p jiffies
  2.     jiffies = $3 = 5540265294
復制代碼

2、局部變量的解析比較復雜。
Vmcore搜集的僅為故障當時內存使用情況的一個快照，是靜態信息，無法進行動態調試(雖然聽說可以，但沒見過~~)，對於某個進程而言，在Vmcore中能發掘的進程上下文信息，通常只有堆棧和寄存器的值。而我們了解，通常局部變量在棧中分配，但也可能直接使用寄存器保存，所以可以(也只能)通過“尋找局部變量跟堆棧或寄存器的關系”來解析局部變量的值。所以這里分兩種情況：
1）位於棧中的局部變量
這種情況比較常見，此時，局部變量必然位於某一級函數的堆棧中，該局部變量可能通過指針一級級向底層函數傳遞，所以可能位於多個函數的堆棧中，可以從不同的函數堆棧中解析。但解析會比較困難，難點在於難以確認相關變量在堆棧中的具體位置，解析方法很靈活，需要結合相關源代碼，仔細分析流程，找到關鍵的點，更多的取決於分析者的經驗和代碼理解能力。
如下以實例說明解析過程：
vmcore中某阻塞的進程有如下的堆棧：

  1.     crash> bt 9242
  2.     PID: 9242 TASK: ffff8805f3a21540 CPU: 4 COMMAND: "xxx"
  3.      #0 [ffff8805f3a23428] schedule at ffffffff814f8b42
  4.      #1 [ffff8805f3a234f0] schedule_timeout at ffffffff814f9a6d
  5.      #2 [ffff8805f3a235a0] __down at ffffffff814fa992
  6.      #3 [ffff8805f3a235f0] down at ffffffff81097c11
  7.      #4 [ffff8805f3a23620] xfs_buf_lock at ffffffffa0523433 [xfs]
  8.      #5 [ffff8805f3a23650] _xfs_buf_find at ffffffffa05235f2 [xfs]
  9.      #6 [ffff8805f3a236c0] xfs_buf_get at ffffffffa05237db [xfs]
  10.      #7 [ffff8805f3a23700] xfs_buf_read at ffffffffa0523e4c [xfs]
  11.      #8 [ffff8805f3a23730] xfs_trans_read_buf at ffffffffa0519a98 [xfs]
  12.      #9 [ffff8805f3a23780] xfs_read_agf at ffffffffa04cfd26 [xfs]
  13.     #10 [ffff8805f3a237c0] xfs_alloc_read_agf at ffffffffa04cfe99 [xfs]
  14.     #11 [ffff8805f3a237f0] xfs_alloc_fix_freelist at ffffffffa04d28a1 [xfs]
  15.     #12 [ffff8805f3a238d0] xfs_alloc_vextent at ffffffffa04d2e16 [xfs]
復制代碼

可以看出，進程阻塞在信號量上，需要解析如下函數中xfs_buf_t *bp變量的值，以確認其中bp->b_sema信號量的狀態。

  1. void
  2.     xfs_buf_lock(
  3.         xfs_buf_t        *bp)
  4.     {
  5.         trace_xfs_buf_lock(bp, _RET_IP_);
  7.         if (atomic_read(&bp->b_io_remaining))
  8.             blk_run_address_space(bp->b_target->bt_mapping);
  9.         down(&bp->b_sema);
  10.         XB_SET_OWNER(bp);
  12.         trace_xfs_buf_lock_done(bp, _RET_IP_);
  13.     }
復制代碼

該變量是通過入參從上級函數傳入的，而跟蹤上級函數會發現其為在上級函數_xfs_buf_find中分配的局部變量，解析方法有兩種：

A、在上級函數中通過該變量與堆棧的關系解析
bp變量是在上級函數_xfs_buf_find定義局部變量，那么其通常會在該級棧中分配空間。但難點還在於如何確認該變量在堆棧中的位置，關鍵在於找到“寄存器和堆棧關聯”的地方，還得分析關鍵代碼流程：

  1. _xfs_buf_find(
  2.         xfs_buftarg_t        *btp,    /* block device target        */
  3.         xfs_off_t        ioff,    /* starting offset of range    */
  4.         size_t            isize,    /* length of range        */
  5.         xfs_buf_flags_t        flags,
  6.         xfs_buf_t        *new_bp)
  7.     {
  8.         xfs_off_t        range_base;
  9.         size_t            range_length;
  10.         xfs_bufhash_t        *hash;
  11.         xfs_buf_t        *bp, *n;
  13.         range_base = (ioff << BBSHIFT);
  14.         range_length = (isize << BBSHIFT);
  15.     ...
  16.     found:
  17.         spin_unlock(&hash->bh_lock);
  19.         /* Attempt to get the semaphore without sleeping,
  20.          * if this does not work then we need to drop the
  21.          * spinlock and do a hard attempt on the semaphore.
  22.          */
  23.         if (down_trylock(&bp->b_sema)) {
  24.             if (!(flags & XBF_TRYLOCK)) {
  25.                 /* wait for buffer ownership */
  26.                 xfs_buf_lock(bp);
  27.                 XFS_STATS_INC(xb_get_locked_waited);
  28.     ...
復制代碼

可以看到，bp是作為xfs_buf_lock函數的入參傳入的，那這里應該會通過寄存器或其它方式進行傳參，則必然會對bp所在的堆棧位置進行操作，由此應能找到bp在堆棧中的位置。
反匯編相關代碼：

  1. crash> dis -l _xfs_buf_find
  2.     /usr/src/debug/kernel-2.6.32-220.el6/linux-2.6.32-220.el6.x86_64/fs/xfs/linux-2.6/xfs_buf.c: 431
  3.     0xffffffffa05234f0 <_xfs_buf_find>: push %rbp
  4.     0xffffffffa05234f1 <_xfs_buf_find+1>: mov %rsp,%rbp
  5.     0xffffffffa05234f4 <_xfs_buf_find+4>: push %r15
  6.     0xffffffffa05234f6 <_xfs_buf_find+6>: push %r14
  7.     ...
  8.     0xffffffffa05235e6 <_xfs_buf_find+246>: mov %rcx,%rdi
  9.     0xffffffffa05235e9 <_xfs_buf_find+249>: mov %rcx,-0x58(%rbp) //可以看出rbp偏移0x58即為入參bp的值
  10.     0xffffffffa05235ed <_xfs_buf_find+253>: callq 0xffffffffa05233e0 <xfs_buf_lock>//此處調用xfs_buf_lock
  11.     ...
復制代碼

找到調用xfs_buf_lock函數的地方，在此之前准備入參，操作了堆棧-0x58(%rbp) ，可以看出rbp偏移0x58即為入參bp的值
再看看堆棧中-0x58(%rbp)中的內容具體是啥：

  1. crash> bt -f 9242
  2.     PID: 9242 TASK: ffff8805f3a21540 CPU: 4 COMMAND: "xxx"
  3.      #0 [ffff8805f3a23428] schedule at ffffffff814f8b42
  4.         ffff8805f3a23430: 0000000000000082 ffff8805f3a234a8
  5.         ffff8805f3a23440: 0000000181164d0e ffff880c20518300
  6.         ffff8805f3a23450: 00051200f3a21b00 ffff880c20518300
  7.         ffff8805f3a23460: 00051200f3a21540 ffff8805f3a21af8
  8.         ffff8805f3a23470: ffff8805f3a23fd8 000000000000f4e8
  9.         ffff8805f3a23480: ffff8805f3a21af8 ffff880c20e1a080
  10.         ffff8805f3a23490: ffff8805f3a21540 ffff8805f3a234d8
  11.         ffff8805f3a234a0: 0000000000000246 ffff880c1d102400
  12.         ffff8805f3a234b0: 0000000000000246 ffff8805f3a234d8
  13.         ffff8805f3a234c0: ffff8802ecd784b8 7fffffffffffffff
  14.         ffff8805f3a234d0: ffff8805f3a235a8 7fffffffffffffff
  15.         ffff8805f3a234e0: 0000000000000200 ffff8805f3a23598
  16.         ffff8805f3a234f0: ffffffff814f9a6d
  17.     ...
  18.      #5 [ffff8805f3a23650] _xfs_buf_find at ffffffffa05235f2 [xfs]
  19.         ffff8805f3a23658: ffff8805f563e600 ffff8802ecd78480
  20.         ffff8805f3a23668: 0001400500000000 ffff8805f563e690
  21.         ffff8805f3a23678: ffff8805f3a236b8 0000000000000001
  22.         ffff8805f3a23688: ffff8805f3a21af8 ffff8808fe07c0c0
  23.         ffff8805f3a23698: 0000000000014005 000000003a382231
  24.         ffff8805f3a236a8: 0000000000000001 ffff8805f563e0c0
  25.     rsp--> ffff8805f3a236b8: ffff8805f3a236f8 ffffffffa05237db
復制代碼

我們知道：
（1）棧的地址是向低地址延伸的，也就是說壓棧時，sp(棧頂地址)減小。
（2）第一個壓棧的上級函數的返回地址，所以其中的ffffffffa05237db為上級函數的返回地址（從上述堆棧中可以明顯看出~）
在_xfs_buf_find()函數反匯編的第一句，就對rbp(即上級堆棧棧幀指針)進行了壓棧，所以 ffff8805f3a236f8為rbp。
0xffffffffa05234f0 <_xfs_buf_find>: push %rbp
此時的rsp應該就是ffff8805f3a236b8：接下來：
0xffffffffa05234f1 <_xfs_buf_find+1>: mov %rsp,%rbp
那么此時的rbp也就等於ffff8805f3a236b8，那么rbp-0x58就是ffff8802ecd78480即為我們苦苦尋找的bp指針了！！
通過如下命令驗證下該bp指針的內容，其類型為xfs_buf_t結構體：

  1. crash> struct xfs_buf_t ffff8802ecd78480
  2.     struct xfs_buf_t {
  3.       b_rbnode = {
  4.         rb_parent_color = 18446612143895321536,
  5.         rb_right = 0x0,
  6.         rb_left = 0x0
  7.       },
  8.       b_file_offset = 500099736064,
  9.       b_buffer_length = 512,
  10.       b_hold = {
  11.         counter = 6
  12.       },
  13.       b_lru_ref = {
  14.         counter = 3
  15.       },
  16.       b_flags = 3145844,
  17.       b_sema = {
  18.         lock = {
  19.           raw_lock = {
  20.             slock = 151718155
  21.           }
  22.         },
  23.         count = 0,
  24.         wait_list = {
  25.           next = 0xffff88008c3f38c8,
  26.           prev = 0xffff8805f3a235a8
  27.         }
  28.       },
復制代碼

內容輸出正常，應說明解析是正確的。
從該結構體內容可以看出，該xfs_lock被其它進程占用了，且等待隊列中有進程正在等待該鎖，進一步分析wait_list可以得到每個等待進行的相關信息，這里不再贅述具體方法。

B、在本級或下級函數中通過該變量與堆棧的關系解析
解析關鍵在於：需要找到引用該變量的關鍵點，比如這里的down(&bp->b_sema)函數，以bp變量所為入參，那么就必然會對該變量進行操作，比如通過寄存器傳參到down函數中，在此可以尋找到蛛絲馬跡。
首先，需要對xfs_buf_lock函數進行反匯編：

  1. crash> dis -l xfs_buf_lock
  2.     /usr/src/debug/kernel-2.6.32-220.el6/linux-2.6.32-220.el6.x86_64/fs/xfs/linux-2.6/xfs_buf.c: 933
  3.     0xffffffffa05233e0 <xfs_buf_lock>: push %rbp
  4.     0xffffffffa05233e1 <xfs_buf_lock+1>: mov %rsp,%rbp
  5.     0xffffffffa05233e4 <xfs_buf_lock+4>: sub $0x20,%rsp
  6.     0xffffffffa05233e8 <xfs_buf_lock+8>: mov %rbx,-0x18(%rbp)
  7.     0xffffffffa05233ec <xfs_buf_lock+12>: mov %r12,-0x10(%rbp)
  8.     0xffffffffa05233f0 <xfs_buf_lock+16>: mov %r13,-0x8(%rbp)
  9.     0xffffffffa05233f4 <xfs_buf_lock+20>: nopl 0x0(%rax,%rax,1)
  10. ...
  11.     /usr/src/debug/kernel-2.6.32-220.el6/linux-2.6.32-220.el6.x86_64/fs/xfs/linux-2.6/xfs_buf.c: 940
  12.     0xffffffffa052342a <xfs_buf_lock+74>: lea 0x38(%rbx),%rdi
  13.     0xffffffffa052342e <xfs_buf_lock+78>: callq 0xffffffff81097bd0 
  14.     /usr/src/debug/kernel-2.6.32-220.el6/linux-2.6.32-220.el6.x86_64/fs/xfs/linux-2.6/xfs_trace.h: 325
  15.     0xffffffffa0523433 <xfs_buf_lock+83>: mov 0x2976e(%rip),%r11d # 0xffffffffa054cba8 <__tracepoint_xfs_buf_lock_done+8>
  16.     /usr/src/debug/kernel-2.6.32-220.el6/linux-2.6.32-220.el6.x86_64/fs/xfs/linux-2.6/xfs_buf.c: 943
  17.     0xffffffffa052343a <xfs_buf_lock+90>: mov 0x8(%rbp),%r12
復制代碼

找到關鍵點：調用down()函數的地方，然后可以發現，在call down之前，就行了相關寄存器操作，可以推測是進行傳參相關的准備。
可以發現有
lea 0x38(%rbx),%rdi
對比代碼
down(&bp->b_sema);
可以看出，入參是bp結構體的一個成員，剛好跟0x38偏移對應，由此可推測此時的rbx寄存器為存放bp指針的寄存器。
接下來，需要尋找rbx寄存器跟堆棧的關系，需要找到從rbx向堆棧寫、或從堆棧向rbx讀的相關操作，而在當級函數的反匯編代碼中顯然沒有，需要進入下級函數down()中，看看是否有相關操作，對down()進行反匯編：

  1. crash> dis -l down
  2.     /usr/src/debug/kernel-2.6.32-220.el6/linux-2.6.32-220.el6.x86_64/kernel/semaphore.c: 54
  3.     0xffffffff81097bd0 : push %rbp
  4.     0xffffffff81097bd1 <down+1>: mov %rsp,%rbp
  5.     0xffffffff81097bd4 <down+4>: push %rbx
  6.     0xffffffff81097bd5 <down+5>: sub $0x18,%rsp
  7.     0xffffffff81097bd9 <down+9>: nopl 0x0(%rax,%rax,1)
  8.     0xffffffff81097bde <down+14>: mov %rdi,%rbx
  9.     ...
復制代碼

可以看出，其中第5行對rbx寄存器進行壓棧，bingo!，這正是我們要尋找的，由此說明bp指針的值，必然可以在down()這一級函數的棧中找到。
解析堆棧：

  1. crash> bt -f 9242
  2.     PID: 9242 TASK: ffff8805f3a21540 CPU: 4 COMMAND: "_0605_KLINUX_DF"
  3.      #0 [ffff8805f3a23428] schedule at ffffffff814f8b42
  4.         ffff8805f3a23430: 0000000000000082 ffff8805f3a234a8
  5.         ffff8805f3a23440: 0000000181164d0e ffff880c20518300
  6.         ffff8805f3a23450: 00051200f3a21b00 ffff880c20518300
  7.         ffff8805f3a23460: 00051200f3a21540 ffff8805f3a21af8
  8.         ffff8805f3a23470: ffff8805f3a23fd8 000000000000f4e8
  9.         ffff8805f3a23480: ffff8805f3a21af8 ffff880c20e1a080
  10.         ffff8805f3a23490: ffff8805f3a21540 ffff8805f3a234d8
  11.         ffff8805f3a234a0: 0000000000000246 ffff880c1d102400
  12.         ffff8805f3a234b0: 0000000000000246 ffff8805f3a234d8
  13.         ffff8805f3a234c0: ffff8802ecd784b8 7fffffffffffffff
  14.         ffff8805f3a234d0: ffff8805f3a235a8 7fffffffffffffff
  15.         ffff8805f3a234e0: 0000000000000200 ffff8805f3a23598
  16.         ffff8805f3a234f0: ffffffff814f9a6d
  17.     ...
  18.      #3 [ffff8805f3a235f0] down at ffffffff81097c11
  19.         ffff8805f3a235f8: ffff8805f3a23618 0000000000000292
  20.         ffff8805f3a23608: ffff8802ecd78480 ffff8802ecd78480
  21.         ffff8805f3a23618: ffff8805f3a23648 ffffffffa0523433
  22.      #4 [ffff8805f3a23620] xfs_buf_lock at ffffffffa0523433 [xfs]
  23.         ffff8805f3a23628: 0000000000016ec0 0000000000016ec0
  24.         ffff8805f3a23638: ffff8808fe07c0c0 ffff8802ecd78490
  25.         ffff8805f3a23648: ffff8805f3a236b8 ffffffffa05235f2
復制代碼

down()的堆棧在第#3級，再看看down()的反匯編代碼的頭三句：

  1. 0xffffffff81097bd0 : push %rbp
  2. 0xffffffff81097bd1 <down+1>: mov %rsp,%rbp
  3. 0xffffffff81097bd4 <down+4>: push %rbx
復制代碼

顯然，接下來壓棧的是rbp，即ffff8805f3a23648是rbp，即上一級堆棧的棧幀指針。
第3句，即對rbx壓棧，說明rbx(即我們要找的bp指針的值)就位於down()函數堆棧中的第3個位置(第1為上級函數返回地址、第2為rbp)，即：
ffff8802ecd78480
所以，我們找到了。。。。

2）位於寄存器中的局部變量
由於Vmcore只是一個內存快照的靜態數據，所以其中保存的進程上下文中，只保存了最后一級函數執行時的寄存器內容，所以，如果相關局部變量位於最后一級函數中，且用寄存器保存，那么此時可以直接通過相關進程的bt上下文得到：

  1. crash> bt 9242
  2.     PID: 9242 TASK: ffff8805f3a21540 CPU: 4 COMMAND: "_0605_KLINUX_DF"
  3.      #0 [ffff8805f3a23428] schedule at ffffffff814f8b42
  4.      #1 [ffff8805f3a234f0] schedule_timeout at ffffffff814f9a6d
  5.      #2 [ffff8805f3a235a0] __down at ffffffff814fa992
  6.      #3 [ffff8805f3a235f0] down at ffffffff81097c11
  7.      #4 [ffff8805f3a23620] xfs_buf_lock at ffffffffa0523433 [xfs]
  8.      #5 [ffff8805f3a23650] _xfs_buf_find at ffffffffa05235f2 [xfs]
  9.      #6 [ffff8805f3a236c0] xfs_buf_get at ffffffffa05237db [xfs]
  10.     ..
  11.     #24 [ffff8805f3a23f80] system_call_fastpath at ffffffff8100b0f2
  12.         RIP: 0000003885e0ed2d RSP: 00007f43871e36e0 RFLAGS: 00003297
  13.         RAX: 0000000000000002 RBX: ffffffff8100b0f2 RCX: 0000000000000000
  14.         RDX: 0000000000000241 RSI: 0000000000000241 RDI: 00007f43871e3710
  15.         RBP: 00007f43871e365c R8: 00007f43871df440 R9: 0000000000100000
  16.         R10: 0000000000000000 R11: 0000000000003293 R12: ffffffff8117a830
  17.         R13: ffff8805f3a23f78 R14: 00007f43871e3710 R15: 00007f43871e391c
  18.         ORIG_RAX: 0000000000000002 CS: 0033 SS: 002b
復制代碼

但是，如果需要解析的局部變量位於中間流程，且使用寄存器保存，且不能在最后一級函數執行時的進程上下文中體現，那么此類局部變量就無法解析了。


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 iOS: Crash文件解析(一) NSNull Crash處理 （NullSafe 的原理） iOS通過dSYM文件分析crash Android P的native crash處理流程 iOS 數組越界 Crash處理經驗 Swift app中的Crash捕獲與處理 Asp.Net Core 文件上傳處理 asp.net core 文件的處理 [iOS]使用symbolicatecrash分析crash文件 .NET Core 如何上傳文件及處理大文件上傳
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM