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

Issue 778387 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Tabs not repainting until resized (or after a long delay) with large session

Project Member Reported by creis@chromium.org, Oct 25 2017

Issue description

Chrome Version: 62.0.3202.62 with --site-per-process
OS: Windows 10

What steps will reproduce the problem?
(1) Start Chrome with --site-per-process and essentially no process limit (--renderer-process-limit=400)
(2) Load a very large session (e.g., 300 tabs).
(3) Try switching between tabs, or opening a new tab and navigating.

What is the expected result?
On a powerful Z840 machine with plenty of RAM, Chrome should be responsive.  I've been using this mode on M62 with such a workload for 2 weeks with almost no problems.

What happens instead?
Today, tabs stopped painting when I switched between them.  They would remain white for 10s of seconds, until the renderer unresponsive dialog was shown.  Strangely, resizing the tab makes it paint and be responsive again!

The problem persisted after restarting Chrome and restoring all tabs.  I haven't tested yet with a smaller session or without the flags, so I'm not sure if those are required.

lfg@ wondered might be related to surfaces refactoring from Viz/MUS?
 

Comment 1 by creis@chromium.org, Oct 25 2017

Hmm, after restarting a second time with the same flags, I'm not seeing the problem and everything seems responsive again.

After a third restart, there's a 1-2 second delay on repainting some tabs, but it's much less than before.

I'm not sure that means it's a WontFix, but I don't yet see what causes the very long delays.  Does this type of issue sound familiar from any other bugs, though?

Comment 2 by fsamuel@google.com, Oct 25 2017

Cc: rjkroege@chromium.org weiliangc@chromium.org sadrul@chromium.org kylec...@chromium.org samans@chromium.org
Labels: Needs-Triage-M62
Components: -Blink>Compositing Blink>Scheduling
I'm seeing this too but unrelated to site isolation. I think it's some kind of scheduling issue or deadlock in IPC because the browser "stop loading" button has no effect.

For example, when restarted to update to 62.0.3202.62 I had about 8 windows with maybe 10 tabs in each on average, and the only way to get every tab displaying was to wait for the unresponsive page dialog and kill the contents. Then reload each killed page once there were no more spinners.

Maybe other bugs have been filed on this (I presume so) but that's for other teams do figure out. This is not Blink>Compositing.

Comment 5 by lfg@chromium.org, Oct 26 2017

Cc: schenney@chromium.org
schenney@, when killing the contents through the kill dialog a crash dump should be uploaded. Can you check about:crashes and see if there's anything there?

I have a lot of crashes from previous dates (to long ago to remember why) but nothing from my experience yesterday.
Status: Available (was: Untriaged)
Could you try recording a trace when this happens and attaching it here? Please also include the scheduler.debug category.

Comment 8 by laforge@google.com, Nov 8 2017

Components: -Internals>Viz Internals>Services>Viz
Migrating from Internals>Viz to Internals>Services>Viz.
Re #0: It is still reproducible? Could you share a trace with us if it is?
Labels: Needs-Feedback
NextAction: 2018-04-23
NextAction: ----
Status: WontFix (was: Available)
Sorry, I'm not seeing this anymore.  I'll WontFix it.  schenney@, feel free to reopen if you're still seeing it.

Sign in to add a comment