记Android12上一个原生bug引起的system_servercrash

欢迎使用Markdown编辑器 一. 现象描述

近日测试上报一个几乎必现的crash，描述如下: 现象: launcher编辑状态与锁屏解锁交互时系统概率性重启 操作步骤:

进入launcher组件编辑状态按电源键灭屏后亮屏，锁屏界面上滑解锁launcher编辑状态向右或向左滑动重复1，2，3 步骤多次操作，观察系统重启情况 二. 初步分析

随后在提供的日志中搜索“crash”，果然发现了以下的报错信息打印：

从日志中大概能分析出3点重要的信息

crash 发生在system_server进程报错打印是Could not find consume time for seq=3513crash大概发生在input时间在被client端处理完毕后向 inputdispatchar 发送 finsh的阶段

除此之外，在大概5s后，crash进一步引起了anr，根据anr的提示信息：** ANR in gesture monitor owned by pid:1045. Reason: PointerEventDispatcher0** 可进一步推断，**crash发生在 手势处理的过程中向 inputdispatchar 发送 finsh的阶段 **

三. 分析crash发生的原因 猜想1

根据报错的提示信息和堆栈打印，在结合代码，报错发生在frameworks/native/libs/input/InputTransport.cpp中

上文提到发生crash发生在 手势处理的过程中向 inputdispatchar 发送 finsh的阶段，大概流程如下

client端梳理完事件代用finishInputEvent随后进一步来到图中1的位置，根据seq在容器mConsumeTimes中尝试获取一个时间戳向input端发送finish消息从容器mConsumeTimes中移除该seq对应的对象

crash发生在阶段2，从容器mConsumeTime获取不到该seq对应的对象，然后报错 Could not find consume time for seq=3513，然后根据该类的其他代码得知，mConsumeTime 是一个map类型的容器，在事件分发前，会以事件的seq为key，当前时间为value添加一条记录，当时间被client端处理完毕后然后从该容器中移除对应seq的记录。 结合代码和报错的注释，初步猜想是对应事件的finish调用了两次引发了crash： 为了验证猜想，随后放开了input相关的日志，进行复现，发现发生crash时 对应seq的事件确实调用了两次finish：

猜想是正确的，现在的问题变成了为什么status_t InputConsumer::sendFinishedSignal发生了两次，

进一步猜想

进一步阅读代码得知frameworks/base/core/jni/android_view_InputEventReceiver.cpp中会调用到 InputConsumer::sendFinishedSigna. 对于普通的touch事件来说,调用到InputConsumer::sendFinishedSigna.有两种情况：

情况1 事件被java层的frameworks/base/core/java/android/view/InputEventReceiver.java正常处理完毕后，主动调用finishInputEvent随后再来到natvie层调用到 InputConsumer::sendFinishedSigna. 如下图 情况二 在时间分发阶段，构造了一个java层的事件对象，然后交给java层去处理，java层处理阶段出现了异常，native层的NativeInputEventReceiver捕获到了该异常，NativeInputEventReceiver会发起一次InputConsumer.sendFinishedSignal status_t NativeInputEventReceiver::consumeEvents(JNIEnv* env, bool consumeBatches, nsecs_t frameTime, bool* outConsumedBatch) { ....... bool skipCallbacks = false; for (;;) { uint32_t seq; ........ jobject inputEventObj; switch (inputEvent->getType()) { // 构造 MotionEvent 对象 case AINPUT_EVENT_TYPE_MOTION: { if (kDebugDispatchCycle) { ALOGD("channel '%s' ~ Received motion event.", getInputChannelName().c_str()); } MotionEvent* motionEvent = static_cast<MotionEvent*>(inputEvent); if ((motionEvent->getAction() & AMOTION_EVENT_ACTION_MOVE) && outConsumedBatch) { *outConsumedBatch = true; } inputEventObj = android_view_MotionEvent_obtainAsCopy(env, motionEvent); break; } ........ default: assert(false); // InputConsumer should prevent this from ever happening inputEventObj = nullptr; } if (inputEventObj) { if (kDebugDispatchCycle) { ALOGD("channel '%s' ~ Dispatching input event.", getInputChannelName().c_str()); } env->CallVoidMethod(receiverObj.get(), // 调用java方法，分发事件 gInputEventReceiverClassInfo.dispatchInputEvent, seq, inputEventObj); if (env->ExceptionCheck()) { // 捕获到java层的异常，使得skipCallbacks = true; ALOGE("Exception dispatching input event."); skipCallbacks = true; } env->DeleteLocalRef(inputEventObj); } else { ALOGW("channel '%s' ~ Failed to obtain event object.", getInputChannelName().c_str()); skipCallbacks = true; } } if (skipCallbacks) { ALOGD("NativeInputEventReceiver consumeEvents seq=%u ", seq); // 因为前面捕获到异常，skipCallbacks == ture。 调用mInputConsumer.sendFinishedSignal mInputConsumer.sendFinishedSignal(seq, false); } } }

在上文两处中添加log，复现crash log如下：

可见对于seq 3513 ，正常情况和发生异常的情况都调用了一次InputConsumer.sendFinishedSignal！！！

总结一下目前的线索：在桌面手势分发seq == 3513的事件阶段出现了异常，异常被native层的NativeInputEventReceiver得知，然后发起了一次sendFinishedSignal， 同时java层在对seq ==3513事件处理结束后，主动调用了一次sendFinishedSignal，两次调用sendFinishedSignal进而引发crash。

有新的疑问涌出：

桌面手势分发seq == 3513的事件阶段出现了什么异常为什么正常的情况和异常的情况都触发？ 四. 发现端倪

在native检测到异常的分支里面添加对错误的打印，然后复现问题，发现如下打印，原来是上层发生可空指针问题 但，这个空指针问题怎么会使得 异常分支和正常分支的sendFnishSignal都触发呢？随后在PointerEventDispatcher这个类中发现端倪：

frameworks/base/services/core/java/com/android/server/wm/PointerEventDispatcher.java @Override public void onInputEvent(InputEvent event) { try { if (event instanceof MotionEvent && (event.getSource() & InputDevice.SOURCE_CLASS_POINTER) != 0) { MotionEvent motionEvent = (MotionEvent) event; if (ENABLE_PER_WINDOW_INPUT_ROTATION) { final int rotation = mDisplayContent.getRotation(); if (rotation != Surface.ROTATION_0) { mDisplayContent.getDisplay().getRealSize(mTmpSize); motionEvent = MotionEvent.obtain(motionEvent); motionEvent.transform(MotionEvent.createRotateMatrix( rotation, mTmpSize.x, mTmpSize.y)); } } PointerEventListener[] listeners; synchronized (mListeners) { if (mListenersArray == null) { mListenersArray = new PointerEventListener[mListeners.size()]; mListeners.toArray(mListenersArray); } listeners = mListenersArray; } for (int i = 0; i < listeners.length; ++i) { listeners[i].onPointerEvent(motionEvent); } } } finally { // catch呢？？？？？ finishInputEvent(event, false); } }

如上，分发完事件后，无论是否发生异常都会在finally中调用finishInputEvent，同时虽然有try， final,但没有catch，这就意味着该段逻辑并未捕获任何类型的异常！！！！，真相大白：

为什么正常情况的sendFnishSignal会被触发？ 事件处理结束后触发了 finally 执行了finishInputEvent,随后进一步触发sendFnishSignal为什么异常情况的sendFnishSignal也会被触发？ 首先事件分发阶段发生了异常，但PointerEventDispatcher并没有catch住相关的异常,随后异常被native层的NativeInputEventReceiver获知，进入了异常分支也触发了一次sendFnishSignal。

但，疑问还在继续，这似乎是google的原生的一个bug，为什么谷歌的代码这样处理？无论正常还是异常情况下 java层调用finishInputEvent 触发一次sendFnishSignal，然后native层检测到异常 再触发一次 sendFnishSignal，Java层和native层的代码不像同一个人写的，都考虑到了异常情况要去触发sendFnishSignal，然后就发生了在分发阶段出现异常时同一事件就发生了两次 sendFnishSignal

这么明显的bug，谷歌应该能发现吧？ 果然： 谷歌的修复： 发生异常时native层不再触发sendFnishSignal