由Ctrl+Z引发的系统卡死重启问题分析-低调大师

由Ctrl+Z引发的系统卡死重启问题分析

2016-10-13 640

起因

JT同学拿着手机来找我说用着用着自动重启了，让我看一下，我抓出bugreport一看是system server发生watchdog重启了，然后接着看了一下traces，发现traces比较诡异。

初步分析

为什么说traces诡异？暂且一看

都被thread 31持有的锁给block了，那就看看thread 31在搞什么飞机？

"InputDispatcher" prio=10 tid=31 Native
  | group="main" sCount=1 dsCount=0 obj=0x133d90a0 self=0x7f73f8c800
  | sysTid=1662 nice=-8 cgrp=default sched=0/0 handle=0x7f5f80b440
  | state=S schedstat=( 1388341757 1177043722 12975 ) utm=81 stm=57 core=2 HZ=100
  | stack=0x7f5f70f000-0x7f5f711000 stackSize=1013KB
  | held mutexes=
  kernel: (couldn't read /proc/self/task/1662/stack)
  native: #00 pc 00000000000684e0  /system/lib64/libc.so (__ioctl+4)
  native: #01 pc 0000000000072508  /system/lib64/libc.so (ioctl+100)
  native: #02 pc 000000000002d584  /system/lib64/libbinder.so (_ZN7android14IPCThreadState14talkWithDriverEb+164)
  native: #03 pc 000000000002e050  /system/lib64/libbinder.so (_ZN7android14IPCThreadState15waitForResponseEPNS_6ParcelEPi+104)
  native: #04 pc 000000000002e2c4  /system/lib64/libbinder.so (_ZN7android14IPCThreadState8transactEijRKNS_6ParcelEPS1_j+176)
  native: #05 pc 0000000000025654  /system/lib64/libbinder.so (_ZN7android8BpBinder8transactEjRKNS_6ParcelEPS1_j+64)
  native: #06 pc 00000000000e02cc  /system/lib64/libandroid_runtime.so (???)
  native: #07 pc 0000000000505e64  /data/dalvik-cache/arm64/system@framework@boot.oat (Java_android_os_BinderProxy_transactNative__ILandroid_os_Parcel_2Landroid_os_Parcel_2I+200)
  at android.os.BinderProxy.transactNative(Native method)
  at android.os.BinderProxy.transact(Binder.java:503)
  at android.app.IActivityController$Stub$Proxy.activityStarting(IActivityController.java:172)
  at com.android.server.am.ExtraActivityManagerService.checkStartActivityLocked(ExtraActivityManagerService.java:259)
  at com.android.server.am.ExtraActivityManagerService.checkStartActivityPermission(ExtraActivityManagerService.java:207)
  - locked <0x025805bb> (a com.android.server.am.ActivityManagerService)
  at com.android.server.am.ActivityStackSupervisor.startActivityMayWait(ActivityStackSupervisor.java:983)
  at com.android.server.am.ActivityManagerService.startActivityAsUser(ActivityManagerService.java:3962)
  at android.app.ContextImpl.startActivityAsUser(ContextImpl.java:696)
  at android.app.ContextImpl.startActivityAsUser(ContextImpl.java:675)
  at com.android.server.policy.PhoneWindowManager.startActivityAsUser(PhoneWindowManager.java:3250)
  at com.android.server.policy.PhoneWindowManager.startDockOrHome(PhoneWindowManager.java:6545)
  at com.android.server.policy.PhoneWindowManager.launchHomeFromHotKey(PhoneWindowManager.java:3391)
  at com.android.server.policy.PhoneWindowManager.launchHomeFromHotKey(PhoneWindowManager.java:3342)
  at com.android.server.policy.BaseMiuiPhoneWindowManager.interceptKeyBeforeDispatching(BaseMiuiPhoneWindowManager.java:643)
  at com.android.server.wm.InputMonitor.interceptKeyBeforeDispatching(InputMonitor.java:375)
  at com.android.server.input.InputManagerService.interceptKeyBeforeDispatching(InputManagerService.java:1751)

调用ActivityController的activityStarting接口时阻塞了？

这里说明一下，通过名字我们大概能猜到ActivityController的作用，简单来说就是一个监控器，提供的接口如下：

/**
 * Testing interface to monitor what is happening in the activity manager
 * while tests are running.  Not for normal application development.
 * {@hide}
 */
interface IActivityController
{
    /**
     * The system is trying to start an activity.  Return true to allow
     * it to be started as normal, or false to cancel/reject this activity.
     */
    boolean activityStarting(in Intent intent, String pkg);

    /**
     * The system is trying to return to an activity.  Return true to allow
     * it to be resumed as normal, or false to cancel/reject this activity.
     */
    boolean activityResuming(String pkg);

    /**
     * An application process has crashed (in Java).  Return true for the
     * normal error recovery (app crash dialog) to occur, false to kill
     * it immediately.
     */
    boolean appCrashed(String processName, int pid,
            String shortMsg, String longMsg,
            long timeMillis, String stackTrace);

    /**
     * Early call as soon as an ANR is detected.
     */
    int appEarlyNotResponding(String processName, int pid, String annotation);

    /**
     * An application process is not responding.  Return 0 to show the "app
     * not responding" dialog, 1 to continue waiting, or -1 to kill it
     * immediately.
     */
    int appNotResponding(String processName, int pid, String processStats);

    /**
     * The system process watchdog has detected that the system seems to be
     * hung.  Return 1 to continue waiting, or -1 to let it continue with its
     * normal kill.
     */
    int systemNotResponding(String msg);
}

为什么调用一下这个ActivityController的activityStarting就被block了呢？这个ActivityController是谁？在那个进程中？

继续往下分析，看看都有谁实现了ActivityController

比较可疑的有两个，一个是monkey的，一个是Am的，然后就问了一下JT同学问题发生的场景，是不是在做monkey测试或者执行adb shell am相关的命令操作？他说是的，问题发生当时在执行am命令。

好，问题有了一点眉目，但是为什么执行am命令会导致阻塞并重启呢？继续看代码

        @Override
        public boolean activityStarting(Intent intent, String pkg) {
            synchronized (this) {
                System.out.println("** Activity starting: " + pkg);
            }
            return true;
        }

执行activityStarting需要ActivityController自己本身的锁，如果这个时候拿不到锁就会block system server，那就继续看看这个锁还会被谁用，看了一圈代码，发现锁的粒度都非常小，不像会block的样子，这就是上面为什么说traces比较诡异的原因，block在了不应该block的地方，那接下来怎么办呢？

深入分析

通过初步分析我们觉得调用ActivityController的activityStarting不应该被block，而这次调用是一个binder call，跨进程的，有没有可能没有到达am进程那边？或者am进程出了什么问题？或者另有隐情？赶紧再问问JT同学当时的操作步骤，看能不能重现问题，然后dump一下相关信息，JT同学不愧是专业的测试，操作现场还保留着，执行的一堆命令也还在终端上，赶紧再操作一遍

ps | grep ^u
am monitor
ctrl+z

问题奇迹复现了，点击一个icon去startactivity之后系统就卡死了，赶紧在一分钟内看看am进程的信息

ps | grep am

没有am的信息？那就看看app_process

ps | grep app_process

原来am小伙通过app_process起来之后连名字都没改。。。。

等等，我好像擦觉到了一丝异常？上面为什么要用ctrl+z？赶紧问JT同学，他说这是HH同学敲的命令，难道HH同学是想停止am monitor继续在终端里面输命令吗？如果同样的需求我都是用ctrl+c的啊？他为啥要用ctrl+z，有特别的含义吗？赶紧去问一下HH同学，他说他只是想停止am monitor继续在终端里面输命令，没有特殊含义，而且他都是这么用的？这下问题就看到曙光了，这两个组合键操作虽然都能满足停止当前任务继续输入其他命令的需求，但是ctrl+z和ctrl+c是有本质区别的，在Linux下区别是什么呢？

ctrl-c: ( kill foreground process ) 发送 SIGINT 信号给前台进程组中的所有进程，强制终止程序的执行
ctrl-z: ( suspend foreground process ) 发送 SIGTSTP 信号给前台进程组中的所有进程，常用于挂起一个进程，而并
            非结束进程，用户可以使用使用fg/bg操作恢复执行前台或后台的进程。fg命令在前台恢复执行被挂起的进
            程，此时可以使用ctrl-z再次挂起该进程，bg命令在后台恢复执行被挂起的进程，而此时将无法使用ctrl-z
            再次挂起该进程；
            一个比较常用的功能：
                   正在使用vi编辑一个文件时，需要执行shell命令查询一些需要的信息，可以使用ctrl-z挂起vi，等执行                   完shell命令后再使用fg恢复vi继续编辑你的文件（当然，也可以在vi中使用！command方式执行shell命令，
            但是没有该方法方便）。
ctrl-d: ( Terminate input, or exit shell ) 一个特殊的二进制值，表示 EOF，作用相当于在终端中输入exit后回车；

类似的组合键操作还有以下几个：

ctrl-/    发送 SIGQUIT 信号给前台进程组中的所有进程，终止前台进程并生成 core 文件
ctrl-s   中断控制台输出
ctrl-q   恢复控制台输出
ctrl-l    清屏

看到这里我想有些同学可能已经知道问题的原因了，am monitor执行之后，am进程会向AMS注册一个ActivityController，启动一个activity的时候会回调ActivityController的activityStarting接口，但是HH同学用Ctrl+Z挂起am进程之后，AMS在通过binder call activityStarting的时候就被block了，因为activityStarting是同步调用，虽然binder driver把这次调用的transaction放到了am进程的todo list里面，但是am进程因为是STOPED状态所以不会拿到时间片去执行todo list里面的transaction，进而也不会有reply，就这样system server就被卡住了，瞬间又加重了Android系统的脆弱感。。。

到这就结束了吗？当然没有，我们细心的JT同学又发现说好的一分钟watchdog重启，都等了好几分钟了怎么还没有重启？好问题，继续看代码

代码是最清晰、最好的解释，原来watchdog线程也依赖ActivityController，会调用ActivityController的systemNotResponding，从而导致连watchdog线程也被卡住了，本来说好的一分钟重启就做不到了，近在咫尺的重启代码执行不了，连GOODBYE也没出来就死了，哎，生活就是这样，这就是生活。。。。

                Slog.w(TAG, "*** GOODBYE!");
                Process.killProcess(Process.myPid());
                System.exit(10);

下一步动作

虽然生活总让人无奈，但我们还是要想办法做的更好，接下来会尝试改善watchdog线程依赖ActivityController的机制，不能因为ActivityController出了问题就永远卡住系统，之前就分析过一个monkey导致的系统永远卡住的问题，也是因为在调用ActivityController的systemNotResponding时候卡住:由MONKEY测试引发的跨多个进程的ANDROID系统死锁问题分析

通过下面的步骤可以在所有Android手机上复现这个问题：

am monitor
ctrl+z
随便点击一个桌面图标或者按下home键

微信关注我们

原文链接：https://yq.aliyun.com/articles/254753

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

由ContactsProvider的升级引发的OTA首次开机卡白米问题分析

上午的宁静被一个OTA卡白米问题打破，接下来不断有人反馈不同机型都复现了OTA后卡白米，10.9号OTA升级到10.10号的版本，全机型问题，线刷没有问题，好吧，接下来就根据这些信息开始初步分析log吧！初步分析查看问题log，发现Boot phase到了PHASE_SYSTEM_SERVICES_READY 并且走到了PackageManagerService.systemReady 10-10 15:26:47.762 3152 3152 W ContextImpl: Calling a method in the system process without a qualified user: android.app.ContextImpl.bindService:1295 miui.provider.ExtraGuard.init:69 com.android.server.pm.PackageManagerServiceInjector.initExtraGuard:429 com.android.server.pm.PackageManagerService.syste...

2016-10-14

522

最近在开发一个远程办公的软件。昨天在手机调通，并且成功通过手机打开电脑上的Eclipse撸出来一个HelloWorld。也许不久的将来, 下班后，拿着手机在家写代码了。工作时间直接变成24/24 /7 废话不多说，先来看下面的截图，图片都是手机截图直接通过手机打开一个Windows操作系统。下面打开Eclipse，创建了java工程。相关原理本篇我们简单介绍下。有些低层代码还没有来得及仔细研究，写的有点水。 1. 首先服务器开发一个虚拟桌面，类似阿里云的虚拟镜像一样，然后手机端进行交互。 2. 具体界面通过GLSerfaceView进行绘制。 3. 通过Spice协议传递交互数据代码需要用到C语言函数库。这里armeabi和x86架构下都放置了这两个函数库，保证能够正常在模拟器和真机运行。涉及到的开源框架传输的流媒体框架使用GStreamer SDK下载地址: http://docs.gstreamer.com/display/GstSDK/Installing+the+SDK 教程下载地址: http://docs.gstreamer.com/display/Gst...

2016-10-14

699

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。