Some time ago developed a small screen of the function (as follows:), fruit for a period of time, the test staff said that our mobile phone sometimes does not boot: has been stopped at the start of the interface. I didn't know anything about it at first. No problems were found in the code. And then the problem became more serious.
Then it became more and more serious. The important thing is that this time low probability event, it is difficult to reproduce once, so it is a bit difficult. Finally, through data/anr/traces.txt to find the problem, the following to see the key information:
"WindowManag4 MONITOR | group= "main" scount=1 dscount=0 obj=0x4275d4d8 self=0x57929cb0 | systid=732 nice=-4 sched=0/0 Cgrp=apps handle=1469227632 | schedstat= (1563495873 1380427864 20236)-Waiting to lock <0x427e72d8> (a ljava/lang/object;) held by Tid=1 (Mai N) | [0]:<0006> Landroid/hardware/display/displaymanagerglobal;. Getdisplayinfo (I) landroid/view/displayinfo; (<span style= "color: #FF0000;" >DisplayManagerGlobal.java:108</span>) | [1]:<0008> Landroid/view/display;. Updatedisplayinfolocked () V (display.java:657) | [2]:<0002> Landroid/view/display;. Getmetrics (landroid/util/displaymetrics;) V (display.java:585) | [3]:<0104> Lcom/android/server/display/xunhuoverlaydisplayadapter;. <init> (lcom/android/server/display/displaymanagerservice$syncroot; Lan (<span style= "color: #FF0000;" >xunhuOverlayDisplayAdapter.java:104</span>) | [4]:<0030> Lcom/android/server/display/displaymanagerservice;. Register_xunhuoverlaydisplayadapterlockEd () V (displaymanagerservice.java:994)
"main" prio= 5 Tid=1 MONITOR | group= "main" scount=1 dscount=0 obj=0x422c6cf8 self=0x4182e500 | systid=715 nice=-2 sched=0/0 Cgrp=apps handle=1074631044 | schedstat= (7254851604 2756007452 25767)-Waiting to lock <0x4277acc8> (a Lcom/android/server/display/displaymana Gerservice$syncroot; ) held by Tid=14 (WindowManager) | [0]:<0020> Lcom/android/server/display/displaymanagerservice;. Getdisplayinfo (I) landroid/view/displayinfo; (<span style= "color: #FF0000;" >DisplayManagerService.java:449</span>) | [1]:<0012> Landroid/hardware/display/displaymanagerglobal;. Getdisplayinfo (I) landroid/view/displayinfo; (<span style= "color: #FF0000;" >DisplayManagerGlobal.java:117</span>) | [2]:<0000> Landroid/hardware/display/displaymanagerglobal;. Getcompatibledisplay (ilandroid/view/displayadjustments;) Landroid/view/display; (displaymanagerglobal.java:176)
The key to the above two pieces of information is that waiting to lock appears to be entering a deadlock. Two lock waits are in this file to appear: Displaymanagerglobal.java, so look at Displaymanagerglobal will find the problem:
Public displayinfo getdisplayinfo (int displayid) { try { synchronized (mLock) {<span style= "color: #FF0000;" >//108</span> displayinfo info; if (use_cache) { info = mdisplayinfocache.get (Displayid); if (info! = null) { return info; } } info = mdm.getdisplayinfo (Displayid); <span style= "color: #FF0000;" >//117</span> if (info = = null) { return null; }
The first is here Mlock lock competition. When calling Mdm.getdisplayinfo (Displayid) In this lock, it will call back to Displaymanagerservice, the following code:
Public displayinfo getdisplayinfo (int displayid) { final int callinguid = Binder.getcallinguid (); Final Long token = binder.clearcallingidentity (); try { synchronized (msyncroot) {<span style= "color: #FF0000;" >//449</span> //M:[smartbook]ignore extra display Devicee info if (featureoption.mtk_smartbook_ Support) { if (Displayid = = Mextradisplayid) { return null; } }
Obviously, in the acquisition of Displaymanagerglobal inside the lock: MLock, also need to displaymanagerservice inside the lock msyncroot.
And I developed the small screen function in the Displaymanagerservice Register small screen displayadapter time has acquired the msyncroot lock, so if at the same time ( Register the DisplayAdapter of the small screen) call the following code:
WindowManager wm = (WindowManager) context.getsystemservice (context.window_service); Wm.getdefaultdisplay (). Getmetrics (Metric);
The deadlock is easy to be seen. Because the call to Getdefaultdisplay () At the end of the day will call Displaymanagerglobal Getdisplayinfo this method. And there are lots of other places to call Displaymanagerglobal's getdisplayinfo when booting up.
Share a problem with Android phone not being able to turn off