異常處理函式，在底層【彙編**】做一些處理後，最後呼叫c
介面函式。即使是c
函式，核心異常的處理函式還是cpu
架構相關的，就是函式在arch
下的不同目錄下實現。
當發生指令異常時，彙編**的處理是[
以64位armv8
架構為例]
：對應的彙編**在檔案kernel/arch/arm64/kernel/entry.s
中，el1_undef: /*
* undefined instruction
*/ enable_dbg
mov x0,sp
b do_undefinstr
do_undefinstr
的實現在具體cpu
架構的檔案kernel/arch/arm64/kernel/traps.c
中,不同異常處理一般都呼叫函式arm64_notify_die
，arm64_notify_die
只是做了簡單的處理，最後呼叫die
do_undefinstr
->arm64_notify_die("oops- undefined instruction", regs, &info, 0);
->die
die主要由三個子函式oop_begin,__die
和oop_end
組成，核心異常後的log
主要有這三個函式輸出。
voiddie(const char *str, struct pt_regs *regs, int err)
oops_begin()
沒有列印資訊，log
主要由函式__die
輸出，如backtrace
等staticint __die(const char *str, int err, struct thread_info *thread,
struct pt_regs *regs)
} 如以下列印資訊，都有__die
函式輸出；
[ 140.325767] internal error: oops: 96000045 [#1] preempt smp
[ 140.325800] modules linked in: wlan(o)
[ 140.325870] cpu: 0 pid: 5011 comm: sh tainted: g w o 3.18.20-perf-ga0cfe42 #1
[ 140.325895] hardware name: qualcomm technologiespc i, inc. msm 8996v3 + pmi8994 mtp (dt)
[ 140.325925] task: ffffffc004e8a580 ti: ffffffc05809c000 task.ti:ffffffc05809c000
[ 140.325983] pc is at sysrq_handle_crash+0x14/0x1c
[ 140.326010] lr is at __handle_sysrq+0x9c/0x150
[ 140.332644] process sh (pid: 5011, stack limit = 0xffffffc05809c058)
[ 140.332669] call trace:
[ 140.332712] sysrq_handle_crash+0x14/0x1c
[ 140.332741] write_sysrq_trigger+0x48/0x60
[ 140.332784] proc_reg_write+0x64/0x84
[ 140.332817] vfs_write+0xb8/0x194
[ 140.332842] sys_write+0x44/0x84
[ 140.332872] code: 52800020 b909f420 d5033e9f d2800001 (39000020)
下面看die
的最後乙個函式：oop_end
staticvoid oops_end(unsigned long flags, struct pt_regs *regs, int notify)
函式oop_exit
和panic
在cpu
無關的檔案kernel/kernel/panic.c
中oops_exit
會輸出資訊---[end trace da227214a82491b9 ]---
oops_exit(void)->print_oops_end_marker()
->pr_warn("---[end trace %016llx ]---\n", (unsigned long long)oops_id);
核心異常後，整機會重啟，重啟就是在函式panic
控制的，方法就是進入死迴圈，利用硬體看門狗超時使系統重啟。
voidpanic(const char *fmt, ...)
mdelay(panic_timer_step); }
} }dataabort
異常並非都會導致系統重啟，虛擬記憶體的缺頁機制也是通過資料訪問異常實現的。
entry(v6_early_abort)
mrc p15,0, r1, c5, c0, 0 @ get fsr
mrc p15,0, r0, c6, c0, 0 @ get far
b do_dataabort
arch/arm/mm/fault.c:550:do_dataabort(unsignedlong addr, unsigned int fsr, struct pt_regs *regs)
asmlinkagevoid __exception
do_dataabort(unsignedlong addr, unsigned int fsr, struct pt_regs *regs)
do_dataabort
的異常處理並沒有呼叫arm_notify_die("",regs, &info, fsr, 0);
而是inf->fn(addr,fsr & ~fsr_lnx_pf, regs): c0115920 t do_page_fault
do_page_fault->
__do_kernel_fault(mm,addr, fsr, regs); /*
*oops. the kernel tried to access some page that wasn't present. */
staticvoid
__do_kernel_fault(structmm_struct *mm, unsigned long addr, unsigned int fsr,
struct pt_regs *regs)
直接重啟，沒有進入異常處理流程，沒有backtrace
等資訊的儲存。利用pstore
機制，儲存系統最後時間執行的kernellog
和logcat.
storm worker異常重啟
storm supervisor.out日誌中有報錯 supervisor info shutting down and clearing state for id ae1ad586 ce5c 459a 8f32 30410683b4d6.current supervisor time 140816...
異常重啟 關機充電，手機不斷重啟問題分析
程式設計師android 力薦 android 開發者需要的必備技能 一 lk 階段重啟 二 在kernel關機充電階段重啟 三 關閉異常掉電機制 在低電量時，插著充電器關機充電，手機會不斷重啟。低電量關機充電不斷重啟問題在lk 階段重啟的log如下 unplugged usb charger in...
讓程式異常退出後自動重啟
程式 freeeim.exe 遇到問題異常退出，是否重啟？類似的情況我們似乎碰見過，很多程式都有這個功能 這是怎麼實現的呢？經 過一番努力，在msdn找到了setunhandledexceptionfilter函式，利用它，可以實現這個功能。其實這個過程叫做seh structured except...