Bug #118571
IOVDEV-32876【内部】【VC1】【0106】【台架】【EE环境】【副屏】【设置】副屏冻屏五分钟左右自动恢复了
Status: | CLOSED | Start date: | 2023-06-06 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | CD TEST-方永红 | % Done: | 0% | |
Category: | 冻屏 | |||
Target version: | - | |||
Need_Info: | -- | Found Version: | 0106 | |
Resolution: | DUPLICATE | Degrated: | -- | |
Severity: | Critical | Verified Version: | ||
Reproducibility: | Every time | Fixed Version: | ||
Test Type: | ST | Root cause: |
Description
环境信息】EE环境
【问题出现时间】:20230606 13:53
【前提条件】:副屏上电,中控已连接
【操作步骤】
1.无任何操作
【实际结果】
1.副屏冻屏五分钟左右自动恢复了
【期望结果】
1.副屏不会冻屏、花屏、黑屏现象
【备注】:
【当前开机次数】:156
【应用版本】:
【硬件版本号】:
【VIN】HRYTTESTVINMGM401
【中控版本号】:03.02.0088.C103
【副屏版本号】:01.00.0106(01.00.0104)
Related issues
History
#2 Updated by CD FW 曹覃刚 about 2 years ago
■ 我的分析
anr_2023-06-06-13-53-33-909
13:53 微信发生ANR
anr_2023-06-06-13-55-20-999
anr_2023-06-06-13-54-20-940
13:54 SYSTEM_SERVER发生ANR,系统重启,恢复正常
SYSTEM_SERVER的ANR,block在下面这个地方,起activity时去获取wakelock,一直获取不到,locked资源一直没释放,block了主线程,导致system_server发生了anr
----------------------------------
"Binder:1496_15" prio=5 tid=155 Native
| group="main" sCount=1 ucsCount=0 flags=1 obj=0x13a89450 self=0xb400007d7f7ef300
| sysTid=4063 nice=-10 cgrp=default sched=0/0 handle=0x7aff94bcb0
| state=S schedstat=( 3651753225 319404349 5696 ) utm=259 stm=105 core=4 HZ=100
| stack=0x7aff854000-0x7aff856000 stackSize=991KB
| held mutexes=
native: #00 pc 00000000000a1c88 /apex/com.android.runtime/lib64/bionic/libc.so (_ioctl+8)
native: #01 pc 000000000005b8d4 /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+156)
native: #02 pc 00000000000666e4 /system/lib64/libhidlbase.so (android::hardware::IPCThreadState::transact(int, unsigned int, android::hardware::Parcel const&, android::hardware::Parcel*, unsigned int)+424)
native: #03 pc 00000000000663dc /system/lib64/libhidlbase.so (android::hardware::BpHwBinder::transact(unsigned int, android::hardware::Parcel const&, android::hardware::Parcel*, unsigned int, std::_1::function<void (android::hardware::Parcel&)>)+80)
native: #04 pc 000000000000e5d0 /system/lib64/android.system.suspend@1.0.so (android::system::suspend::V1_0::BpHwSystemSuspend::_hidl_acquireWakeLock(android::hardware::IInterface*, android::hardware::details::HidlInstrumentor*, android::system::suspend::V1_0::WakeLockType, android::hardware::hidl_string const&)+308)
native: #05 pc 0000000000003188 /system/lib64/libhardware_legacy.so (acquire_wake_lock+360)
native: #06 pc 00000000000984a4 /system/lib64/libandroid_servers.so (android::nativeAcquireSuspendBlocker(_JNIEnv*, _jclass*, _jstring*)+68)
at com.android.server.power.PowerManagerService.nativeAcquireSuspendBlocker(Native method)
at com.android.server.power.PowerManagerService.access$1200(PowerManagerService.java:139)
at com.android.server.power.PowerManagerService$NativeWrapper.nativeAcquireSuspendBlocker(PowerManagerService.java:799)
at com.android.server.power.PowerManagerService$SuspendBlockerImpl.acquire(PowerManagerService.java:5048)
- locked <0x0c054105> (a com.android.server.power.PowerManagerService$SuspendBlockerImpl)
at com.android.server.power.PowerManagerService.updateSuspendBlockerLocked(PowerManagerService.java:3413)
at com.android.server.power.PowerManagerService.updatePowerStateLocked(PowerManagerService.java:2170)
at com.android.server.power.PowerManagerService.acquireWakeLockInternal(PowerManagerService.java:1417)
- locked <0x05f98b91> (a java.lang.Object)
at com.android.server.power.PowerManagerService.access$4600(PowerManagerService.java:139)
at com.android.server.power.PowerManagerService$BinderService.acquireWakeLock(PowerManagerService.java:5175)
at android.os.PowerManager$WakeLock.acquireLocked(PowerManager.java:2720)
at android.os.PowerManager$WakeLock.acquire(PowerManager.java:2686)
- locked <0x06ea655a> (a android.os.Binder)
at com.android.server.wm.ActivityTaskSupervisor.acquireLaunchWakelock(ActivityTaskSupervisor.java:1340)
at com.android.server.wm.Task.startPausingLocked(Task.java:5877)
at com.android.server.wm.Task.startPausingLocked(Task.java:5765)
at com.android.server.wm.TaskDisplayArea.lambda$pauseBackTasks$6(TaskDisplayArea.java:1533)
at com.android.server.wm.TaskDisplayArea$$ExternalSyntheticLambda4.accept(unavailable:-1)
at com.android.server.wm.Task.forAllLeafTasks(Task.java:3920)
at com.android.server.wm.WindowContainer.forAllLeafTasks(WindowContainer.java:1748)
at com.android.server.wm.TaskDisplayArea.pauseBackTasks(TaskDisplayArea.java:1526)
at com.android.server.wm.Task.resumeTopActivityInnerLocked(Task.java:6374)
at com.android.server.wm.Task.resumeTopActivityUncheckedLocked(Task.java:6212)
at com.android.server.wm.RootWindowContainer.resumeFocusedTasksTopActivities(RootWindowContainer.java:2436)
at com.android.server.wm.ActivityStarter.startActivityInner(ActivityStarter.java:1836)
at com.android.server.wm.ActivityStarter.startActivityUnchecked(ActivityStarter.java:1576)
at com.android.server.wm.ActivityStarter.executeRequest(ActivityStarter.java:1183)
at com.android.server.wm.ActivityStarter.execute(ActivityStarter.java:671)
- locked <0x04dee350> (a com.android.server.wm.WindowManagerGlobalLock)
at com.android.server.wm.ActivityTaskManagerService.startActivityAsUser(ActivityTaskManagerService.java:1229)
at com.android.server.wm.ActivityTaskManagerService.startActivityAsUser(ActivityTaskManagerService.java:1201)
at com.android.server.wm.ActivityTaskManagerService.startActivity(ActivityTaskManagerService.java:1150)
at android.app.IActivityTaskManager$Stub.onTransact(IActivityTaskManager.java:920)
at com.android.server.wm.ActivityTaskManagerService.onTransact(ActivityTaskManagerService.java:5074)
at android.os.Binder.execTransactInternal(Binder.java:1179)
at android.os.Binder.execTransact(Binder.java:1143)
----------------------------------
■ 下一步计划
需要调查,起activity时获取wakelock一直没反应的原因
#3 Updated by CD FW 曹覃刚 about 2 years ago
- Assignee changed from CD FW 曹覃刚 to CD FW王武军
#4 Updated by CD FW王武军 about 2 years ago
- Assignee changed from CD FW王武军 to CD FW 曹覃刚
6月7日进展
1、基本信息
第一次出现anr是在13:53:34,是微信应用出现了anr,anr的原因是卡在界面绘制的方法中;
第二次出现anr是在13:54:20,是system_server出现anr,anr的原因是卡在了PowerManagerService.nativeAcquireSuspendBlocker的native方法。
system_server的anr触发了watchdog超时,导致系统重启了。
从两个方向展开调查:
1)在微信发生anr时,系统的状态
分析了13:49:50.785-13:53:34这个时间段的日志,发现在一段时间范围内
a) tlogdshc service的不断重启和被杀,日志如下:
06-06 13:50:50.788 0 0 I [12427.187916] init: processing action (sys.tlog.tlogdshc.active=1) from (/system/etc/init/tlogd.rc:195)
06-06 13:50:50.792 0 0 I [12427.188598] init: starting service 'tlogdshc'...
06-06 13:50:50.892 0 0 I [12427.288660] init: Service 'tlogdshc' (pid 6675) exited with status 0 oneshot service took 0.095000 seconds in background
06-06 13:50:50.892 0 0 I [12427.288683] init: Sending signal 9 to service 'tlogdshc' (pid 6675) process group...
06-06 13:50:50.892 0 0 I [12427.288824] libprocessgroup: Successfully killed process cgroup uid 0 pid 6675 in 0ms
b) 微信启动存在超时被杀的情况
06-06 13:53:23.795 1496 1620 W ActivityManager: Process ProcessRecord{933c084 7309:com.tencent.mm:opengl_detector/u0a99} failed to attach
06-06 13:53:23.795 1496 1620 I am_process_start_timeout: [0,7309,10099,com.tencent.mm:opengl_detector]
06-06 13:53:23.795 1496 1620 W ActivityManager: Forcing bringing down service: ServiceRecord{2c3e7bf u0 com.tencent.mm/com.tencent.matrix.openglleak.detector.OpenglIndexDetectorService}
06-06 13:53:23.795 1496 1620 I ActivityManager: Killing 7309:com.tencent.mm:opengl_detector/u0a99 (adj -10000): start timeout
06-06 13:53:23.795 1496 1620 I am_kill : [0,7309,com.tencent.mm:opengl_detector,-10000,start timeout]
06-06 13:53:23.795 1496 1625 I libprocessgroup: Successfully killed process cgroup uid 10099 pid 7309 in 0ms
c)出现anr时 hht_ota_mgr event_loop 服务和进程cpu暂用率很高
06-06 13:54:03.416 1496 7414 E ActivityManager: CPU usage from 10210ms to 25667ms later (2023-06-06 13:53:43.700 to 2023-06-06 13:53:59.157):
06-06 13:54:03.416 1496 7414 E ActivityManager: 99% 2763/hht_ota_mgr: 40% user + 59% kernel
06-06 13:54:03.416 1496 7414 E ActivityManager: 18% TOTAL: 7.7% user + 11% kernel
06-06 13:54:03.416 1496 7414 E ActivityManager: CPU usage from 62ms to 404ms later (2023-06-06 13:53:33.552 to 2023-06-06 13:53:33.895):
06-06 13:54:03.416 1496 7414 E ActivityManager: 100% 2763/hht_ota_mgr: 36% user + 64% kernel
06-06 13:54:03.416 1496 7414 E ActivityManager: 104% 2773/event_loop: 40% user + 64% kernel
06-06 13:54:03.416 1496 7414 E ActivityManager: 18% TOTAL: 7.7% user + 11% kernel
小结:从微信anr前的一段时间来看,tlogdshc和hht_ota_mgr的异常表现可能会对系统性能造成影响,需要相关的组跟进分析
2)system_server的anr发生的根本原因
从PowerManagerService.nativeAcquireSuspendBlocker方法展开,该方法的周边逻辑是否存在耗时和阻塞的情况(目前还未具体展开)
2、下一步
从PowerManagerService.nativeAcquireSuspendBlocker方法展开分析
#5 Updated by CD FW王武军 about 2 years ago
- Assignee changed from CD FW 曹覃刚 to CD FW王武军
#6 Updated by CD FW 曹覃刚 about 2 years ago
a) tlogdshc service的不断重启和被杀,日志如下:
06-06 13:50:50.788 0 0 I [12427.187916] init: processing action (sys.tlog.tlogdshc.active=1) from (/system/etc/init/tlogd.rc:195)
06-06 13:50:50.792 0 0 I [12427.188598] init: starting service 'tlogdshc'...
06-06 13:50:50.892 0 0 I [12427.288660] init: Service 'tlogdshc' (pid 6675) exited with status 0 oneshot service took 0.095000 seconds in background
06-06 13:50:50.892 0 0 I [12427.288683] init: Sending signal 9 to service 'tlogdshc' (pid 6675) process group...
06-06 13:50:50.892 0 0 I [12427.288824] libprocessgroup: Successfully killed process cgroup uid 0 pid 6675 in 0ms
已新建任务 #118631 给system组的同学
#7 Updated by CD FW王武军 about 2 years ago
6月8日最新进展
关于PowerManagerService.nativeAcquireSuspendBlocker卡主的问题与118602问题一样,在118602有问题的更新。
#8 Updated by CD FW 曹覃刚 about 2 years ago
- Status changed from New to RESOLVED
- Assignee changed from CD FW王武军 to CD TEST-方永红
- Resolution changed from -- to DUPLICATE
转JIRA跟踪
#9 Updated by CD TEST-方永红 almost 2 years ago
- Status changed from RESOLVED to VERIFIED
7.25
客户已关闭,同步关闭
#10 Updated by CD TEST-方永红 almost 2 years ago
- Status changed from VERIFIED to CLOSED