Chrome version: 69.0.3497.00
Device: Pixel 2

A friend was complaining about frequent ANR's while using Chrome, particularly with custom tabs. I've attached the bug report for it. It has a couple of ANR instances and looking at the stacks the common thing is a CountDownLatch wait coming from OAuth2TokenService.hasOAuth2RefreshToken. Here is the stack trace:

"main" prio=5 tid=1 Waiting
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x7467ef40 self=0xe8448000
  | sysTid=7363 nice=-10 cgrp=default sched=0/0 handle=0xec018494
  | state=S schedstat=( 1134900814 45906024 2983 ) utm=98 stm=14 core=4 HZ=100
  | stack=0xff42f000-0xff431000 stackSize=8MB
  | held mutexes=
  at java.lang.Object.wait(Native method)
  - waiting on <0x0910512a> (a java.lang.Object)
  at java.lang.Thread.parkFor$(Thread.java:2137)
  - locked <0x0910512a> (a java.lang.Object)
  at sun.misc.Unsafe.park(Unsafe.java:358)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:190)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:868)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1021)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1328)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:232)
  at bAB.c(SourceFile:52)
  at bAB.d(SourceFile:62)
  at bAB.c(SourceFile:77)
  at org.chromium.chrome.browser.signin.OAuth2TokenService.hasOAuth2RefreshToken(SourceFile:41)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:326)
  at android.os.Looper.loop(Looper.java:160)
  at android.app.ActivityThread.main(ActivityThread.java:6669)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

The method does do a disk read on the UI thread, but looking at the UMA recorded for the time taken in the cache update, Signin.AndroidPopulateAccountCacheWaitingTime, we're less than ~5 seconds at the 99th percentile. Maybe there is nothing actionable here but figured I'd file a bug.

 

Deleted: bugreport-walleye-PPR2.181005.003-2018-09-28-00-05-44.zip 4.8 MB

bugreport-walleye-PPR2.181005.003-2018-09-28-00-05-44.zip 4.8 MB Download