android sw watchdog and How to Debug

╰+哭是因爲堅強的太久メ 2022-05-13 02:46 181阅读 0赞

Android 平台实现了一个软件的WatchDog来监护SystemServer。SystemServer无疑是Android平台中最重要的进程了，里面运行了整个平台中绝大多数的服务。  
在这个进程中运行着近50个线程，任何一个线程死掉都可能导致整个系统死掉。SystemServer退出反而问题不大，因为 init进程会重新启动它，但是它死锁就麻烦了，因为整个系统就没法动了。  
在 SystemServer里运行的服务中有很多的服务，具体可以在  
framework/base/services/java/com/android/SystemServer中找到  
最重要的几个服务应该数ActivityManager、WindowManager和 PowerManager。  
  
软件的WatchDog主要就是确保这几个服务发生死锁之后，退出SystemServer进程，让init进程重启它，让系统回到可用状态。

## 如何在service中添加watchDog? ##

以WindowManagerServeice为例，   
  
  
首先在构造函数中把自身加入到watchdog monitor服务中：  
  
  
private WindowManagerService(Context context, PowerManagerService pm,  
            boolean haveInputMethods) \{   
.............  
 // Add ourself to the Watchdog monitors.  
  Watchdog.getInstance().addMonitor(this);  
  
  
\}  
  
  
然后每个被监护的Service必须实现Watchdog.Monitor接口，这个接口只要实现一个函数monitor，这个函数实现非常简单：  
  
  
// Called by the heartbeat to ensure locks are not held indefnitely (for deadlock detection).  
    public void monitor() \{   
        synchronized (mWindowMap) \{ \}  
        synchronized (mKeyguardTokenWatcher) \{ \}  
    \}  
 它去锁一下对象，什么也不做，然后就返回。如果对象没有死锁，这个过程就会很顺利。如果对象死锁了，这个函数就会挂在这里。

## WatchDog如何工作？ ##

在WatchDog启动之后，开始跑run函数。该函数内部为一个无限循环。  
public void run() \{   
        boolean waitedHalf = false;  
        while (true) \{   
            mCompleted = false;  
            mHandler.sendEmptyMessage(MONITOR);------发送MESSAGE由HeartbeatHandler处理监控的各个对象的状态  
            ...  
            while (timeout > 0 && !mForceKillSystem) \{   
                    try \{   
                        wait(timeout); ----等待HeartbeatHandler处理结果  
                        \} catch (InterruptedException e) \{   
                    \}  
                    timeout = TIME\_TO\_WAIT - (SystemClock.uptimeMillis() - start);  
                    //TIME\_TO\_WAIT的默认时间为30s。此为第一次等待时间，WatchDog判断对象是否死锁的最长处理时间为1Min。  
                \}  
              
                  
        \}  
\}  
一开始就会发送一个MONITOR的Message，由HeartbeatHandler负责接收并处理。同时会等待30秒，等待HeartbeatHandler的处理结果。然后才会进行下一步动作。  
在HeartbeatHandler中将会作如下处理：  
public void handleMessage(Message msg) \{   
            switch (msg.what) \{   
                case MONITOR: \{   
                ...  
                final int size = mMonitors.size();  
                    for (int i = 0 ; i < size ; i++) \{   
                        mCurrentMonitor = mMonitors.get(i);  
                        mCurrentMonitor.monitor();  
                    \}//依次去调用监护对象的monitor接口，实现对其的监护。  
                 synchronized (Watchdog.this) \{   
                        mCompleted = true;  
                        mCurrentMonitor = null;  
                    \}//如果监护的对象都正常，则会很快运行到这里，并对mCompleted赋值为true，表示对象正常返回。mCompleted值初始为false。  
    ...\}  
  \}  
\}  
  
  
  
  
同时在run函数中：if (mCompleted && !mForceKillSystem) \{   
                    // The monitors have returned.  
                    waitedHalf = false;  
                    continue;  
                   \}//如果所有对象在30s内能够返回，则会得到mCompleted = true;则本次监护就结束，返回继续下一轮监护。  
  
  
  
如果在30s内，monitor对象未能返回，mCompleted 值即为false，则会运行到run方法中该语句：  
  
  
if (!waitedHalf) \{   
                    // We've waited half the deadlock-detection interval.  Pull a stack  
                    // trace and wait another half.  
                    ArrayList<Integer> pids = new ArrayList<Integer>();  
                    pids.add(Process.myPid());  
                    ActivityManagerService.dumpStackTraces(true, pids, null, null);.....dump出trace文件，将有助于我们对watchdog问题的解决  
                    waitedHalf = true;  
                    continue;  
                \}  
  
  
然后跳出该循环，继续一轮循环就将会走到run方法如下语句，非死锁是不会走到的：  
  
  
// If we got here, that means that the system is most likely hung.  
  
  
            final String name = (mCurrentMonitor != null) ?  
                    mCurrentMonitor.getClass().getName() : "null";  
if (!Debug.isDebuggerConnected()) \{   
                if (Build.TYPE.equals("eng") || Build.TYPE.equals("userdebug")) \{   
                    Slog.w(TAG, "\*\*\* WATCHDOG KILLING THE SYSTEM: " + name);...............发生watchdog的重要LOG  
  
  
                    // Give some extra time to make sure CrashMonitorService reacts to  
                    // the dropbox entry before the crash  
                    SystemClock.sleep(2000);  
  
  
                    forceCrashDump();  
                \} else \{   
                    Slog.w(TAG, "\*\*\* WATCHDOG KILLING SYSTEM PROCESS: " + name);  
                    Process.killProcess(Process.myPid());  
                    System.exit(10);  
                \}

## watchdog 的类型： ##

1：android.server.ServerThread被block，LOG如下：

02:06:22.571 W/Watchdog( 307): \*\*\* WATCHDOG KILLING THE SYSTEM: null

2：诸如windowManagerService ,activityManagerService等死锁，LOG如下：  
02:06:22.571 W/Watchdog( 307): \*\*\* WATCHDOG KILLING THE SYSTEM: activityManagerService

## 如何DEBUG watchdog? ##

第一种类型的watchdog,我们要首先看trace.txt中serverThread的调用栈. 为什么呢？  
因为system server启动服务 要分两个过程， 一个是init1()和 init2(),  
前者是启动native service， 比如：surfaceFlinger, AudioFlinger...  
后者就是启动android services, 比如： activityManager, WindowManager...  
而启动android services是在serverThread中进行，代码如下：  
  
  
public static final void init2() \{   
        Slog.i(TAG, "Entered the Android system server!");  
        Thread thr = new ServerThread();  
        thr.setName("android.server.ServerThread");  
        thr.start();  
    \}  
其次，如果遇到调用了native的代码，就可以用gdb或者crash继续debug.  
  
  
第二种类型 看trace.txt中对应死锁进程的调用栈。