New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 777206 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Chrome frequently beachballs on macOS

Reported by alex.gay...@gmail.com, Oct 22 2017

Issue description

UserAgent: 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:
 
Screen Shot 2017-10-22 at 1.51.51 PM.png
157 KB View Download

Comment 1 by meh...@chromium.org, Oct 22 2017

Labels: Stability-Hang Needs-Feedback
Thanks for the report. Can you please grab a sample in the Activity.app from the hanging Chrome process and attach it here? Thanks in advance.
Labels: Needs-Triage-M62

Comment 3 Deleted

Project Member

Comment 4 by sheriffbot@chromium.org, Oct 25 2017

Cc: meh...@chromium.org
Labels: -Needs-Feedback
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
Cc: divya.pa...@techmahindra.com
Labels: Triaged-ET Needs-Feedback
@Reporter: Could you please respond to C#1.


I attempted to, not sure what happened.
sample.txt
779 KB View Download
Project Member

Comment 7 by sheriffbot@chromium.org, Oct 26 2017

Labels: -Needs-Feedback
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

Comment 8 by meh...@chromium.org, Oct 26 2017

Cc: rsesek@chromium.org
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.

Comment 9 by rsesek@chromium.org, Oct 26 2017

Components: -UI UI>Browser>Passwords
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]
bug-777206.txt
969 KB View Download
Owner: kolos@chromium.org
Status: Assigned (was: Unconfirmed)
Maxim, can you take a look at this?
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.
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.

Comment 13 by kolos@chromium.org, Oct 26 2017

Cc: cfroussios@chromium.org
It is probably because of https://chromium-review.googlesource.com/c/chromium/src/+/608971 I'll take a closer look tomorrow.
Status: Started (was: Assigned)
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. 

Project Member

Comment 17 by bugdroid1@chromium.org, 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

Labels: Merge-Request-63
Based on description, UX was awful. If it is possible, let's merge it.

The CL replaces regular expression with manual search algorithm. 
Project Member

Comment 19 by sheriffbot@chromium.org, Nov 4 2017

Labels: -Merge-Request-63 Merge-Review-63 Hotlist-Merge-Review
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
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?
Status: Fixed (was: Started)
Alright, we can wait until M64. 
Labels: -Merge-Review-63 Merge-Rejected-63
Rejecting merge to M63 based on comment #21.
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.
AutofillHang.png
107 KB View Download
Components: Speed
dravorek@: thanks for pointing out. that's sad :( Now I regret that we didn't merge it to M63. 
Cc: gov...@chromium.org
Components: -Speed
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.
Labels: ReleaseBlock-Stable M-63 OS-Windows
Labels: -Merge-Rejected-63 Merge-Approved-63
Approving merge to M63 branch 3239 based on comments #18, #23 and #25. Please merge ASAP as we're cutting M63 stable RC soon. 
Cc: rogerm@chromium.org
kolos@ is in Germany. rogerm@ could you pls merge CL listed at #17 to M63 branch 3239 ASAP?
Merged via the Gerrit UI. Update message should be posted here shortly.
Project Member

Comment 30 by bugdroid1@chromium.org, Dec 4 2017

Labels: -merge-approved-63 merge-merged-3239
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

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.
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.
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