Issue metadata
Sign in to add a comment
|
Chrome frequently beachballs on macOS
Reported by
alex.gay...@gmail.com,
Oct 22 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36 Steps to reproduce the problem: I'm not sure what triggers this What is the expected behavior? No beachballing, smooth operation. What went wrong? Starting recently (probably since the 62 upgrade, but I can't asy with certainty), fair regularly while browsing Chrome beachablls (parent process goes to 100% CPU). I haven't tracked down any particular factor which triggers this (though it feels like video sites, youtube/netflix, trigger it more regularly -- or maybe they're just more annoying). The issue is manifestly in the parent process's UI thread, as the browser is entirely non-interactive during the beachball. The beachball generally persists for 5-15 seconds and then returns to normal state. Using about:profiler I have attempted to track down this issue (as an aside, there appears to be a bug where when comparing two snapshots in about:profiler the "max runtime" column disappears). I'm attaching a screenshot of about:profiler which shows the top runtimes for the browser process. It clearly singles out the "Notify" method of simple_watcher. Unfortunately this appears to be a generic dispatch system, so I'm not sure how useful it is. Did this work before? Yes 61 I believe Chrome version: 62.0.3202.62 Channel: stable OS Version: OS X 10.13.0 Flash Version:
,
Oct 23 2017
,
Oct 25 2017
Thank you for providing more feedback. Adding requester "mehmet@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 26 2017
@Reporter: Could you please respond to C#1.
,
Oct 26 2017
I attempted to, not sure what happened.
,
Oct 26 2017
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 26 2017
Thanks for the attached sample. rsesek@: Can you please take a look at the sample? Can you see what is the reason for the hanging process? Thank you.
,
Oct 26 2017
Lots of time being spent in re2 from the password manager.
2377 autofill::mojom::PasswordManagerDriverStubDispatch::Accept(autofill::mojom::PasswordManagerDriver*, mojo::Message*) (in Google Chrome Framework) load address 0x10576a000 + 0xd8f11b [autofill_driver.mojom.cc:1710]
2377 password_manager::ContentPasswordManagerDriver::PasswordFormsParsed(std::__1::vector<autofill::PasswordForm, std::__1::allocator<autofill::PasswordForm> > const&) (in Google Chrome Framework) load address 0x10576a000 + 0x44a8693 [content_password_manager_driver.cc:205]
2377 password_manager::PasswordManager::CreatePendingLoginManagers(password_manager::PasswordManagerDriver*, std::__1::vector<autofill::PasswordForm, std::__1::allocator<autofill::PasswordForm> > const&) (in Google Chrome Framework) load address 0x10576a000 + 0x3f2cf8e [password_manager.cc:526]
1245 password_manager::PasswordFormManager::DoesManage(autofill::PasswordForm const&, password_manager::PasswordManagerDriver const*) const (in Google Chrome Framework) load address 0x10576a000 + 0x3f1fd65 [password_form_manager.cc:340]
: 839 autofill::CalculateFormSignature(autofill::FormData const&) (in Google Chrome Framework) load address 0x10576a000 + 0x2da0f94 [stringpiece.h:50]
,
Oct 26 2017
Maxim, can you take a look at this?
,
Oct 26 2017
Just to be sure about the methodology: Do we have confidence that this is the culprit and not just a random measurement? The screenshot in the original report showed a ton of time spent on the IO thread and the password manager does not live on the IO thread.
,
Oct 26 2017
I think so. The BirthThread is the IOThread, but it's calling ::Notify, which in Mojo is used to signal handles for receipt on another thread, which in this case is likely the main thread. Beachballing would also only occur if the main thread goes unresponsive.
,
Oct 26 2017
It is probably because of https://chromium-review.googlesource.com/c/chromium/src/+/608971 I'll take a closer look tomorrow.
,
Nov 2 2017
,
Nov 2 2017
Is ths related to https://chromium-review.googlesource.com/c/chromium/src/+/741592?
,
Nov 2 2017
In my understanding, no. If the attachment in #9 is collected correctly, the problem is form signature computing which is time-consuming. In https://chromium-review.googlesource.com/c/chromium/src/+/608971, we started using form signature for PasswordFormManager matching. It was landed to M62.
,
Nov 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5659382b63b2b407fb817af1321441061a07e6cf commit 5659382b63b2b407fb817af1321441061a07e6cf Author: Maxim Kolosovskiy <kolos@chromium.org> Date: Fri Nov 03 21:22:18 2017 [Password Manager] Don't use RE2 for computing form signatures Form signature are widely used for form matching, but regular expression are too slow. See the bug for details. This CL excludes RE2. Bug: 777206 Change-Id: I9ff8a7a2bfad243b44cd36ba4eef49ee502a852d Reviewed-on: https://chromium-review.googlesource.com/750802 Reviewed-by: Roger McFarlane <rogerm@chromium.org> Commit-Queue: Maxim Kolosovskiy <kolos@chromium.org> Cr-Commit-Position: refs/heads/master@{#513915} [modify] https://crrev.com/5659382b63b2b407fb817af1321441061a07e6cf/components/autofill/core/browser/form_structure_unittest.cc [modify] https://crrev.com/5659382b63b2b407fb817af1321441061a07e6cf/components/autofill/core/common/BUILD.gn [delete] https://crrev.com/187e23a1b6de89d7a2b79b4f47c3bfaafa1b59ec/components/autofill/core/common/DEPS [modify] https://crrev.com/5659382b63b2b407fb817af1321441061a07e6cf/components/autofill/core/common/signatures_util.cc
,
Nov 4 2017
Based on description, UX was awful. If it is possible, let's merge it. The CL replaces regular expression with manual search algorithm.
,
Nov 4 2017
This bug requires manual review: DEPS changes referenced in bugdroid comments. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 5 2017
Before we approve merge to M63 branch, could you please change listed #17 is well baked/verified in Canary, having enough automation coverage and safe to merge to M63? Also this is regressed in M62, can this wait until M64?
,
Nov 6 2017
Alright, we can wait until M64.
,
Nov 6 2017
Rejecting merge to M63 based on comment #21.
,
Dec 4 2017
Just FYI, this isn't mac specific. Happens on two of my Windows 10 Machines with Fall Creators Update. This causes fairly regular (around every 1-15 minutes) 10s+ complete UI hangs even if the tab in focus is a simple text file like an rfc.
,
Dec 4 2017
dravorek@: thanks for pointing out. that's sad :( Now I regret that we didn't merge it to M63.
,
Dec 4 2017
govind@: FYI. Can we check how severe the issue is? I know that it is super late for M63. But the fix is just replacing regular expressions with identical algorithm w/o RE.
,
Dec 4 2017
,
Dec 4 2017
Approving merge to M63 branch 3239 based on comments #18, #23 and #25. Please merge ASAP as we're cutting M63 stable RC soon.
,
Dec 4 2017
kolos@ is in Germany. rogerm@ could you pls merge CL listed at #17 to M63 branch 3239 ASAP?
,
Dec 4 2017
Merged via the Gerrit UI. Update message should be posted here shortly.
,
Dec 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b0deaac9f2fdbbd0a15b02617c47c66fcb8a2296 commit b0deaac9f2fdbbd0a15b02617c47c66fcb8a2296 Author: Maxim Kolosovskiy <kolos@chromium.org> Date: Mon Dec 04 18:26:47 2017 [Password Manager] Don't use RE2 for computing form signatures Form signature are widely used for form matching, but regular expression are too slow. See the bug for details. This CL excludes RE2. Bug: 777206 Change-Id: I9ff8a7a2bfad243b44cd36ba4eef49ee502a852d Reviewed-on: https://chromium-review.googlesource.com/750802 Reviewed-by: Roger McFarlane <rogerm@chromium.org> Commit-Queue: Maxim Kolosovskiy <kolos@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#513915}(cherry picked from commit 5659382b63b2b407fb817af1321441061a07e6cf) Reviewed-on: https://chromium-review.googlesource.com/806295 Cr-Commit-Position: refs/branch-heads/3239@{#632} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [modify] https://crrev.com/b0deaac9f2fdbbd0a15b02617c47c66fcb8a2296/components/autofill/core/browser/form_structure_unittest.cc [modify] https://crrev.com/b0deaac9f2fdbbd0a15b02617c47c66fcb8a2296/components/autofill/core/common/BUILD.gn [delete] https://crrev.com/bfbdead2ae09f2ce799395e314c47d4519f6044d/components/autofill/core/common/DEPS [modify] https://crrev.com/b0deaac9f2fdbbd0a15b02617c47c66fcb8a2296/components/autofill/core/common/signatures_util.cc
,
Dec 6 2017
I apparently had too much time on my hands and tried to look into how a simple regex could use over 10s. It doesn't seem like there's a huge string that's getting matched. It seems like there's over 4000 pending_login_managers_ in PasswordManager::CreatePendingLoginManagers from irccloud.com running in the background. Getting all the allocations/deallocations from RE2 out of the way will most likely alleviate this. But I wonder if there's a way for a malicious site to increase that number to a degree that it will even affect the new implementation.
,
Dec 7 2017
On chrome://password-manager-internals/ I have "Number of forms: 12" and "Number of pending login managers (after): 21" at some point of 21. I wonder whether we are leaking anything. 4000 pending_login_managers_ sounds a bit extreme. These numbers are from loading irccloud.com and being logged into 8 channels.
,
Dec 7 2017
The number should be slowly growing in the background while messages arrive. The case where I had 4000 was after a couple of days without refreshing the tab. I guess further details of this issue are tracked by 786941 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by meh...@chromium.org
, Oct 22 2017