[Galaxy S8+] Entire device often hangs/reboots |
|||||||||||
Issue descriptionRepro on: 64.0.3282.29, Galaxy S8 Plus SM-G955U1 (Adreno 540), NRD90M No repro on: 63.0.3239.111, same device After browsing news sites on Chrome 64 beta for 10 minutes or more, then performing one of these actions: A) Tapping on a link that opens an external app via intent B) Tapping on tab switcher button C) Tapping on system home button the entire device sometimes hangs. The hang sometimes lasts 5 to 10 seconds and then goes back to normal, but sometimes it lasts indefinitely (more than a minute), at which point the device eventually reboots itself. I've needed to hard reset about ten times over the holidays. I switched to Chrome stable (63) for a few days and didn't run into the problem again (and I never had the problem before this month). Attached one bugreport taken an hour after a hang-into-auto-reboot after clicking on a twitter.com link that goes to an app intent (Dec 31), and another bugreport taken an hour after tapping on home button caused a hang-into-auto-reboot (Jan 2). Because they were taken a bit late, mainly the "At Last ANR" section is interesting, in both of them it shows an intent-related deadlock: "Binder:3124_1F" prio=5 tid=210 Runnable | group="main" sCount=0 dsCount=0 obj=0x15e68d30 self=0x7f75557800 | sysTid=12711 nice=-10 cgrp=default sched=0/0 handle=0x7f705fe450 | state=R schedstat=( 333041448034 116046961538 751879 ) utm=21287 stm=12017 core=5 HZ=100 | stack=0x7f70504000-0x7f70506000 stackSize=1005KB | held mutexes= "mutator lock"(shared held) at com.android.server.IntentResolver.remove_all_objects(IntentResolver.java:660) at com.android.server.IntentResolver.unregister_intent_filter(IntentResolver.java:647) at com.android.server.IntentResolver.removeFilterInternal(IntentResolver.java:207) at com.android.server.IntentResolver.removeFilter(IntentResolver.java:192) at com.android.server.am.ActivityManagerService$2.removeFilter(ActivityManagerService.java:1257) at com.android.server.am.ActivityManagerService$2.removeFilter(ActivityManagerService.java:1256) at com.android.server.am.ActivityManagerService.removeReceiverLocked(ActivityManagerService.java:21931) at com.android.server.am.ActivityManagerService.unregisterReceiver(ActivityManagerService.java:21908) - locked <0x015b68ec> (a com.android.server.am.ActivityManagerService) at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:485) at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:3652) at android.os.Binder.execTransact(Binder.java:573) "main" prio=5 tid=1 Blocked | group="main" sCount=1 dsCount=0 obj=0x7622de38 self=0x7fa74c7a00 | sysTid=3124 nice=-2 cgrp=default sched=0/0 handle=0x7fabf1aa98 | state=S schedstat=( 855845772373 461540239781 1434228 ) utm=45902 stm=39682 core=0 HZ=100 | stack=0x7ffc464000-0x7ffc466000 stackSize=8MB | held mutexes= at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:22775) - waiting to lock <0x015b68ec> (a com.android.server.am.ActivityManagerService) held by thread 210 at android.app.ActivityManagerNative.broadcastStickyIntent(ActivityManagerNative.java:122) at android.app.ActivityManagerNative.broadcastStickyIntent(ActivityManagerNative.java:112) at com.android.server.BatteryService$17.run(BatteryService.java:1711) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at com.android.server.SystemServer.run(SystemServer.java:625) at com.android.server.SystemServer.main(SystemServer.java:467) at java.lang.reflect.Method.invoke!(Native method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1520) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1410) Also FWIW, attached a logcat taken ~2-3 minutes after a 10 second hang tapping homescreen button from http://latimes.com homepage (although I don't see a smoking gun there). Also attached chrome://version output with "variations". Assigning to dskiba@ as current stability sheriff, feel free to reassign.
,
Jan 3 2018
Found relevant Android bug: b/70582745 there com.nytimes.android registering 12000 LOCALE_CHANGED receivers. Checked bugreports and voila: * In bugreport-2017-12-31-17-50-40 com.chrome.beta registered 665 receivers. * In bugreport-2018-01-02-14-00-42 com.chrome.beta registered 782 receivers. The command to check how many LOCALE_CHANGED receivers are there: adb shell dumpsys activity broadcasts | grep 'Action: "android.intent.action.LOCALE_CHANGED"' | wc -l There was this CL which changed location of registerReceiver(ACTION_LOCALE_CHANGED): https://chromium-review.googlesource.com/c/chromium/src/+/729145, and it landed in M64. I don't understand how it can cause the issue, but it seems the only place where Chrome registers LOCALE_CHANGED receiver, all other places are in Android.
,
Jan 3 2018
BTW in b/70582745 Chrome version is 64.0.3282.12, and com.nytimes.android has 6 WebViews.
,
Jan 3 2018
That code looks correct to me. There's should be one registration per tab/webview, not ideal, but shouldn't be horrible either
,
Jan 3 2018
Ahh, the problem is this block should run only if mWebContentsAccessibility is newly created: https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/ContentViewCoreImpl.java?rcl=941cdfd0c27614f34e03ea96a7782b4152c352f8&l=1232 easy fix
,
Jan 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/66fc0c4a7931f84436b3c770ef6ad90e17dfd713 commit 66fc0c4a7931f84436b3c770ef6ad90e17dfd713 Author: Bo Liu <boliu@chromium.org> Date: Wed Jan 03 23:23:13 2018 android: Fix WebContentsAccessibility init state Only call onAttachedToWindow during init, not every time WebContentsAccessibility is retrieved. Bug: 798629 Change-Id: I5a7036dc1e6dac00b1a0bb250eefc18e36cebf72 Reviewed-on: https://chromium-review.googlesource.com/849393 Reviewed-by: Dmitry Skiba <dskiba@chromium.org> Commit-Queue: Bo <boliu@chromium.org> Cr-Commit-Position: refs/heads/master@{#526859} [modify] https://crrev.com/66fc0c4a7931f84436b3c770ef6ad90e17dfd713/content/public/android/java/src/org/chromium/content/browser/ContentViewCoreImpl.java
,
Jan 4 2018
,
Jan 4 2018
[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.
,
Jan 4 2018
keep it open for merging
,
Jan 4 2018
Re #1: FWIW, it does happen when installing Chrome 64 as Chrome Stable (saw a ~30 second freeze) tapping on tab switcher button. Thanks for the quick fix!
,
Jan 4 2018
Also, I saw it today after typing an email in GMail -- it froze for about 15 seconds after pressing "Send". So this matches the theory that http://b/70582745 WebView issue is the same bug.
,
Jan 4 2018
aelias@, can you check number of receivers next time this happens? Using adb shell dumpsys activity broadcasts | grep 'Action: "android.intent.action.LOCALE_CHANGED"' | wc -l or something similar.
,
Jan 5 2018
Any update here?
,
Jan 5 2018
waiting for a working canary so someone confirm it's fixed, I think tonight's canary should be ok, assuming some other unrelated crasher don't get introduced
,
Jan 6 2018
Re: #12: after a 10-second hang on Chrome stable, I ran the dumpsys activity and I have 10986 LOCALE_CHANGED listeners. About 3000 of those are from Chrome beta and 7500 of them are from Chrome "stable" (which is currently M64 as well after I reinstalled it for question #1). I have also been using Chrome canary 65.0.3312.0 but I don't see any LOCALE_CHANGED listeners for it.
,
Jan 6 2018
Canary 65.0.3312.0 contains r526859 so I guess that confirms it's fixed (although note that I never confirmed a repro on M65 earlier).
,
Jan 8 2018
,
Jan 8 2018
This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 8 2018
,
Jan 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/af4e244d3170f9a6f4a0ffc72f50c2aa3202684a commit af4e244d3170f9a6f4a0ffc72f50c2aa3202684a Author: Bo Liu <boliu@chromium.org> Date: Tue Jan 09 13:58:40 2018 [Merge M64] android: Fix WebContentsAccessibility init state Only call onAttachedToWindow during init, not every time WebContentsAccessibility is retrieved. Bug: 798629 Change-Id: I5a7036dc1e6dac00b1a0bb250eefc18e36cebf72 Reviewed-on: https://chromium-review.googlesource.com/849393 Reviewed-by: Dmitry Skiba <dskiba@chromium.org> Commit-Queue: Bo <boliu@chromium.org> Cr-Commit-Position: refs/heads/master@{#526859}(cherry picked from commit 66fc0c4a7931f84436b3c770ef6ad90e17dfd713) TBR: boliu@chromium.org Change-Id: I1f5f9888319189c807de083e2b0a12cee969e8d1 Reviewed-on: https://chromium-review.googlesource.com/857156 Reviewed-by: Bo <boliu@chromium.org> Cr-Commit-Position: refs/branch-heads/3282@{#455} Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840} [modify] https://crrev.com/af4e244d3170f9a6f4a0ffc72f50c2aa3202684a/content/public/android/java/src/org/chromium/content/browser/ContentViewCoreImpl.java
,
Jan 9 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by boliu@chromium.org
, Jan 3 2018