1. 程式人生 > >Android重啟原因分析

Android重啟原因分析

重啟原因分類

1.上層造成重啟

  • system_server被殺
  • watchdog重啟
  • 重要執行緒阻塞

2.kernel造成重啟

  • 空指標
  • 非法地址

3.kernel watchdog造成重啟,原因不確定

  • 記憶體原因
  • nand驅動

log檢視步驟及關鍵字

1. 重啟後的kernel.log或misc/cmdline.log

在log最前面,會有很長的一段,如:

initrd=0x85500000,0x204229 apv="td860-user 4.1.2 MocorDroid4.1.2 eng..20131107.215135 test-keys" mem=512M loglevel=1 console=ttyS1,115200n8 init=/init mtdparts=sprd-nand:256k(spl),512k(2ndbl),256k(params),512k(vmjaluna),10m(modem),3840k(fixnv),3840k(backupfixnv),5120k(dsp),3840k(runtimenv),10m(boot),10m(recovery),250m(system),180m(userdata),20m(cache),256k(misc),1m(boot_logo),1m(fastboot_logo),3840k(productinfo),512k(kpanic) androidboot.mode=panic lcd_id=ID9816 lcd_base=8ff27000 CHR_STATE=0 ram=512M no_console_suspend boot_ram_log=0x8fe00000,0x80000 tdfixnv=0x89060000,0x40000 tdruntimenv=0x890a0000,0x60000 wfixnv=0x90440000,0x40000 wruntimenv=0x90480000,0x60000 productinfo=0x80490000,0x4000 androidboot.serialno=12345678912345 adc_cal=216338536,185339408 fgu_cal=186388584,159845904,7534 fgu_init=2805,7742 

搜尋androidboot.mode,看開機的模式,如果沒有則預設為normal mode,正常開機;上例中為panic,為kernel中出錯導致的重啟。這個值是從ANA_REG_GLB_POR_RST_MONITOR位中獲取到的值,每次獲取完之後會置為0:

rst_mode = ANA_REG_GET(ANA_REG_GLB_POR_RST_MONITOR);
rst_mode &= 0x7FFF;
ANA_REG_SET(ANA_REG_GLB_POR_RST_MONITOR, 0); //clear flag 

這個值是重啟前填入的,如HWRST_STATUS_PANICHWRST_STATUS_ALARM

等。

2. 重啟後的last_kmsg log

此檔案記錄了重啟前的kernel log,搜尋panic確定問題發生在上層還是底層,如果有panic相關資訊一般都是kernel造成的問題,如果有Restarting system則是上層造成的。

案例一:上層空指標引起的重啟

0[   83.522143] Restarting system with command 'special-systemserver-died'.
0[   83.900657] SPRD_WDT watchdog_feeder, margin=20, feed_period=3, sys_cnt = 86225
0[   84.026350] sprd_set_reboot_mode:cmd=special-systemserver-died 

此時是由於上層systemserver出了問題導致重啟,檢視重啟方式是androidboot.mode=special,是system server掛掉引起的重啟,看上去special方式啟動都是上層引起的。

案例二:

【其他】手機處於待機狀態長按Power鍵彈出POP選框不做任何操作還繼續長按Power,手機會自動重啟。
【預置條件】無
【操作步驟】手機處於待機狀態長按Power鍵--彈出POP選框不做任何操作--還繼續長按Power
【實際結果】手機會自動重啟
【預期結果】應正常
【復現概率】Must
【備註說明】對比其他手機無此現象。

分析:last_kmsg中搜索到sprd_set_reboot_mode:cmd=panic,說明是kernel導致的重啟,附件的log中還有!!!! trigger_watch_powerkey !!!! do emergency_restart,說明很可能是主動呼叫重啟,在程式碼中搜索發現

static void trigger_watch_powerkey(void *private)
{
  unsigned long flags;
  local_irq_save(flags);
#ifdef CONFIG_MAGIC_SYSRQ
  handle_sysrq('m');
  handle_sysrq('w');
#endif
  pr_warn("!!!! trigger_watch_powerkey !!!! do emergency_restart\n");
  emergency_restart();
  pr_err("%s should never reach here!\n", __func__);
} 

長按power鍵超過6秒時會呼叫此函式,使得手機重啟,諮詢展訊是為了除錯定屏問題所增加的功能,量產時可以去除。

解決方法:程式碼中註釋掉input_report_key_hook函式的呼叫,Makefile中不編譯input-hook.o庫。

案例三:

【無線熱點】下拉狀態列,點選無線熱點,手機自動重啟
【預置條件】無
【操作步驟】下拉狀態列--多次點選無線熱點
【實際結果】手機自動重啟
【預期結果】無線熱點正常開啟和關閉
【復現概率】經常

分析:last_kmsg中搜索到Kernel panic - not syncing: Fatal exception,說明是kernel導致的重啟,而且打印出堆疊資訊判斷應為WIFI問題,檢視last_log中的kernel log,可能是soft_ap開啟時失敗。

01-01 08:06:06.522 <4>[  296.682000] thr_wait_for_2nd_eth_dev: sap_eth_sema timeout 

解決方法:增加開啟嘗試次數為3次,減小開啟失敗概率。

3. 檢視重啟前的android log

在android log中,搜尋關鍵字 died, 確認是否system server被殺,如果是檢視具體原因。

案例四:開機動畫過後手機自動重啟

分析:

log最後顯示

I/Zygote  (   86): Exit zygote because system server (222) has terminated 

原因是

E/AndroidRuntime(  222): *** FATAL EXCEPTION IN SYSTEM PROCESS: android.server.ServerThread 

ActivityManagerService.java:4182中的空指標導致的,而前面還有一些空指標異常,第1個是

E/SystemServer(  222): java.lang.NullPointerException
E/SystemServer(  222):      at android.sim.SimManagerService.<init>(SimManagerService.java:94)
E/SystemServer(  222):      at com.android.server.ServerThread.run(SystemServer.java:219) 

SimManagerService 94行為mContext.registerReceiver(mReceiver, filter);可能是mContext空指標,而

 Context temp = null;
    try {
        temp = context.createPackageContext("com.android.settings", Context.CONTEXT_IGNORE_SECURITY);
    } catch (NameNotFoundException e) {
        e.printStackTrace();
    };
    mContext = temp; 

所以createPackageContext可能建立失敗導致,temp為null。再回到log

W/System.err(  222): android.content.pm.PackageManager$NameNotFoundException: Application package com.android.settings not found
證實了這一點, 

搜尋“com.android.settings”

E/PackageManager(  222): Package com.android.settings has no signatures that match those in shared user android.uid.system; ignoring! 

發現初始化失敗,可能是簽名或share user id或是版本不匹配導致,匯出Settings.apk,反編譯並檢視AndroidManifest.xml

<manifest android:sharedUserId="android.uid.system" android:versionCode="15" android:versionName="4.0.3-eng..20130516.160103" package="com.android.settings" coreApp="true" xmlns:android="http://schemas.android.com/apk/res/android"> 

android:versionName="4.0.3-eng..20130516.160103",此資訊顯示Settings為20130516號編譯的版本,與測試提供的資訊20130627版本不匹配,最終原因是驅動下載了差異較大的boot.img導致。

解決方法:下載20130516版本的boot.img即可恢復並正常開機。

4. 上層watchdog產生的重啟,檢視重啟前的traces.txt

軟體framework層的WatchDog主要作用:接收系統內部reboot請求,重啟系統;監護SystemServer程序,防止系統死鎖;每30秒檢查一次。在android log, 關鍵字:WATCHDOG KILLING SYSTEM PROCESS 確認是否是watchdog造成的重啟。如果是,則要檢視重啟前的traces.txt,檢查下面3項:

  1. 確認是否有kernel stack
  2. 關鍵字'held', 找到阻塞源頭
  3. 不能被阻塞的執行緒:WindowManager、ActivityManager、PowerManager、ServerThread

案例五:上層AMS、WMS死鎖導致watchdog重啟

"Thread-304" prio=5 tid=4 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41c16ef8 self=0x69b8a8
| sysTid=3040 nice=0 sched=0/0 cgrp=[no-cpu-subsys] handle=7056472
| schedstat=( 0 0 0 ) utm=0 stm=0 core=1
at com.android.server.wm.WindowManagerService.resumeKeyDispatching(WindowManagerService.java:~6346)
- waiting to lock <0x41738e80> (a java.util.HashMap) held by tid=12 (android.server.ServerThread)
at com.android.server.am.ActivityRecord.resumeKeyDispatchingLocked(ActivityRecord.java:554)
at com.android.server.am.ActivityStack$myThread.run(ActivityStack.java:4314)


"android.server.ServerThread" prio=5 tid=12 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x4154a9a8    self=0x32e200
| sysTid=275 nice=-2 sched=0/0 cgrp=[no-cpu-subsys] handle=3607224
| schedstat=( 0 0 0 ) utm=830 stm=262 core=1
at com.android.server.am.ActivityManagerService.getTasks(ActivityManagerService.java:~5389)
- waiting to lock <0x41555738> (a com.android.server.am.ActivityManagerService) held by tid=4 (Thread-304) 

由上面log可知AMS和WMS發生了死鎖,導致了watchdog重啟。

5. 重啟後kernel.log、misc/last_kmsg、dump檔案

核心或hal層出現的錯誤有很多,這裡主要將oops或有堆疊資訊的問題分析方法,主要分為3類:

1.一個.so或多個.so檔案引起的問題,可能產生的問題並不是重啟

案例六:libwebcore.so導致瀏覽器強關(記憶體地址+so)

15:50:05.633 I DEBUG   : pid: 7662, tid: 7677  >>> com.android.browser <<<
15:50:05.633 I DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000008
15:50:05.673 I DEBUG   :          #00  pc 000b852a  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #01  pc 000b887c  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #02  pc 000b6428  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #03  pc 00218852  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #04  pc 000be9c4  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #05  pc 000beaae  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #06  pc 000bf1e8  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #07  pc 000a9242  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #08  pc 000a7f6a  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #09  pc 000a71a8  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #10  pc 000aac4a  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #11  pc 000aaf06  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #12  pc 000b3304  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #13  pc 000b33fa  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #14  pc 00093230  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #15  pc 001e95aa  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #16  pc 001da83e  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #17  pc 001d6544  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #18  pc 001d658c  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #19  pc 001644ac  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #20  pc 00253ba8  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #21  pc 002dee9c  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #22  pc 002e4f24  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #23  pc 002e51f2  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #24  pc 0033ac62  /system/lib/libwebcore.so
15:50:05.673 I DEBUG   :          #25  pc 0033acc8  /system/lib/libwebcore.so 

這是從android log中擷取的資訊,原理是一樣。這種log可以通過addr2line工具進行反編譯,addr2line位於目錄/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin。

命令是addr2line -e -f libwebcore.so 000b852a,libwebcore.so是帶符號表的so,位於/out/target/product/sp8830ec/symbols/system/lib,000b852a是對應的出錯地址。

一個或多個so引起的問題,還可以從網上找個指令碼,把堆疊資訊單獨儲存到檔案中,然後使用指令碼反編譯,會把每個地址對應的源函式反編譯出來,網上有很多這裡就不貼出指令碼了。

2.hal層即非核心層出現地址錯誤產生的重啟問題

案例七:驅動去除光感後開機不斷重啟(so+函式名+偏移地址)

Fatal signal 11 (SIGSEGV) at 0x00000001 (code=1), thread 456 (system_server)
I/DEBUG   (  138): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (  138): Build fingerprint: 'Lenovo/A388t/A388t:4.1.2/MocorDroid4.1.2/A388t_S161_131112.20131121:user/release-keys'
I/DEBUG   (  138): pid: 456, tid: 456, name: system_server  >>> system_server <<<
I/DEBUG   (  138): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000001
I/DEBUG   (  138):     r0 00000001  r1 00000001  r2 00000001  r3 5a07d004
I/DEBUG   (  138):     r4 5aedd2c0  r5 403ff19c  r6 5aedd2c4  r7 00000001
I/DEBUG   (  138):     r8 5a07d004  r9 00000088  sl 00000003  fp 5aedd2b8
I/DEBUG   (  138):     ip 40317e94  sp bea80548  lr 4030e6a1  pc 40211048  cpsr 20000010
……
I/DEBUG   (  138): backtrace:
I/DEBUG   (  138):     #00  pc 00017048  /system/lib/libc.so (strlen+16)
I/DEBUG   (  138):     #01  pc 0000f69d  /system/lib/libutils.so (android::String8::setTo(char const*)+8)
I/DEBUG   (  138):     #02  pc 0001e7d3  /system/lib/libgui.so (android::Sensor::Sensor(sensor_t const*)+38)
I/DEBUG   (  138):     #03  pc 0000e5af  /system/lib/libsensorservice.so (android::HardwareSensor::HardwareSensor(sensor_t const&)+70)
I/DEBUG   (  138):     #04  pc 0000f78f  /system/lib/libsensorservice.so (android::SensorService::onFirstRef()+110)
I/DEBUG   (  138):     #05  pc 0000edd5  /system/lib/libutils.so (android::RefBase::incStrong(void const*) const+38)
I/DEBUG   (  138):     #06  pc 000010d1  /system/lib/libsystem_server.so
I/DEBUG   (  138):     #07  pc 000011eb  /system/lib/libsystem_server.so (system_init+242)
……
D/Zygote  (  140): Process 456 terminated by signal (11)
I/Zygote  (  140): Exit zygote because system server (456) has terminated 

很明顯是Zygote初始化時system server訪問錯誤地址00000001導致初始化失敗產生的重啟,堆疊資訊如下:

#00  pc 00017048  /system/lib/libc.so (strlen+16)
#01  pc 0000f69d  /system/lib/libutils.so   (android::String8::setTo(char const*)+8)
#02  pc 0001e7d3  /system/lib/libgui.so (android::Sensor::Sensor(sensor_t const*)+38)
#03  pc 0000e5af  /system/lib/libsensorservice.so (android::HardwareSensor::HardwareSensor(sensor_t const&)+70)
#04  pc 0000f78f  /system/lib/libsensorservice.so (android::SensorService::onFirstRef()+110) 

1).看上去雖然棧頂是/system/lib/libc.so (strlen+16)時出現的錯誤,但實際是傳過去的引數有問題,問題應是從android::SensorService::onFirstRef()+110這裡開始;

2).找到SensorService.cpp中onFirstRef函式,出錯是在registerSensor( new HardwareSensor(list[i]) );,即初始化HardwareSensor(list[i])出現的問題,可以發現仍然是函式引數地址不正確引起的;

3).而list是ssize_t count = dev.getSensorList(&list);得到的,具體呼叫的是sensors_module_t mSensorModule的getSensorList;

4).mSensorModule是通過status_t err = hw_get_module(SENSORS_HARDWARE_MODULE_ID, (hw_module_t const**)&mSensorModule);進行初始化的,hw_get_module則是hardware中通過SENSORS_HARDWARE_MODULE_ID載入對應so檔案的函式,即sensor.xxxx.so;

5).而sensor.xxxx.so是/device/sprd/common/libs/libsensors_sprd/模組生成的檔案,因此這個getSensorList實際是通過/device/sprd/common/libs/libsensors_sprd/sensors.cpp中sensors__get_sensors_list得到的,檢視錯誤log前面的資訊:

D/Sensors (  456): BmaSensors=1; 1
D/Sensors (  456): SensorHQALSPS: open_device /dev/alsps
D/Sensors (  456): alsps Sensor: get name:: (ft6306_ps)
D/Sensors (  456): SensorHQALSPS: getName =  ft6306_ps
D/Sensors (  456): PnumSensors=3; 2
D/Sensors (  456): activate handle=0; drv=0
D/Sensors (  456): BmaSensor: mEnabled = 0, enabled = 0.
D/Sensors (  456): activate handle=4; drv=1
D/Sensors (  456): SensorHQALSPS::setEnable=0= en=0; newState=0; what=1; mEnabled=0
D/Sensors (  456): HQALSPS ---Proximity::HQALSPS_IOCTL_PROX_OFF=== err=0
D/Sensors (  456): SensorHQALSPS::setEnable=1= en=0; newState=0; what=1; mEnabled=0 

6).再結合問題去除光感後,手機不斷重啟,所以可能是D/Sensors ( 456): PnumSensors=3; 2中,光感、接近感測器的numSensors有問題,而:

mSensors[pls] = new SensorHQALSPS();
numSensors += 
    mSensors[pls]->populateSensorList(sSensorList + numSensors);
……
ALOGD("PnumSensors=%d; %d", numSensors, PlsSensor::numSensors); 

populateSensorList返回的就是AlspsSensor.h定義的numSensors,值為2:

enum
{
    Light   = 0,
    Proximity   = 1,
    numSensors
}; 

所以最後修改為:

enum
{
    Proximity   = 0,
    numSensors
}; 

3.Linux核心引起的Oops問題

對Linux核心來說,Oops就意外著核心出了異常,此時會將產生異常時CPU的狀態,出錯的指令地址、資料地址及其他暫存器,函式呼叫的順序甚至是棧裡面的內容都打印出來,然後根據異常的嚴重程度來決定下一步的操作:殺死導致異常的程序或者掛起系統。

最典型的異常是在核心態引用了一個非法地址,通常是未初始化的野指標Null,這將導致頁表異常,最終引發Oops。分析錯誤原因的原理同第1種問題,vmlinux相當於so的合集,也是通過工具反編譯找到對應的彙編行,同時檢視對應的函式分析原因,這種問題往往比較複雜後面會單獨寫文件總結分析方法。

6. kernel watchdog造成重啟

原因不確定,可能是記憶體原因、nand驅動。