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

Issue 612618 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Browser goes unresponsive in startup with new tab page

Project Member Reported by ssid@chromium.org, May 17 2016

Issue description

I built fairly recent build of chrome on Linux:
src commit a587e3326042a79d8f22d493e63d19f7c3ae1086

I start up chrome and browser remains unresponsive throughout. It was working the the last time I started, when I had opened ~100 tabs and shutdown.

Browser main is held on SyncChannel::Send. Why is this message sent from main thread?

GPU performs CommandExecutor:PutChanged event: from DisplayCompositor takes 3000ms each.

Ideally there should be no functions that make the UI thread non-responsive, is it really required in this case?

I have attached startup trace files from the browser.
 
trace_slow2.json.gz
2.7 MB Download
trace_slow1.json.gz
2.4 MB Download

Comment 1 by piman@chromium.org, May 17 2016

Yes, sync messages are required, the GPU is needed to show the UI at all.

What's surprising is that it takes 3s+ in CommandExecutor:PutChanged
Can you attach the contents of about:gpu?

Comment 2 by ssid@chromium.org, May 17 2016

It is still the same with today's build:
https://crrev.com/0026aed1b09b9d4d06da3ddc402e995bf57bfad8

Is there a work around for this issue?

Comment 3 by ssid@chromium.org, May 17 2016

Summary: Browser goes unresponsive in startup with new tab page (was: Browser goes unresponsive just at startup)
Well it magically works faster now.

I am attaching contents of about:gpu when it is fast.
I can't get it back to slower state now.

I will attache the gpu again if it gets slow.
gpu.html
53.3 KB View Download

Comment 4 by piman@chromium.org, May 17 2016

Labels: -Pri-1 Needs-Feedback Pri-3
Nothing obvious from about:gpu, reasonably standard NVIDIA gpu/driver.

Comment 5 by ssid@chromium.org, May 17 2016

Labels: -Needs-Feedback
Ok, it got slow again, and this is what the gpu page shows now.
gpu_slow.html
53.3 KB View Download

Comment 6 by piman@chromium.org, May 17 2016

No difference, I don't know.

Can you dump the output of `nvidia-smi -q -d memory`?
It could be interesting to see the difference when slow vs when fast.

Are older builds actually better? If so, any chance you might be able to bisect?

Comment 7 by ssid@chromium.org, May 18 2016

Faster version:

 nvidia-smi -q -d memory

==============NVSMI LOG==============

Timestamp                           : Tue May 17 16:34:59 2016
Driver Version                      : 340.96

Attached GPUs                       : 1
GPU 0000:05:00.0
    FB Memory Usage
        Total                       : 1023 MiB
        Used                        : 986 MiB
        Free                        : 37 MiB
    BAR1 Memory Usage
        Total                       : 256 MiB
        Used                        : 8 MiB
        Free                        : 248 MiB

Slower version:

 nvidia-smi -q -d memory

==============NVSMI LOG==============

Timestamp                           : Tue May 17 17:08:28 2016
Driver Version                      : 340.96

Attached GPUs                       : 1
GPU 0000:05:00.0
    FB Memory Usage
        Total                       : 1023 MiB
        Used                        : 1005 MiB
        Free                        : 18 MiB
    BAR1 Memory Usage
        Total                       : 256 MiB
        Used                        : 8 MiB
        Free                        : 248 MiB

Comment 8 by ssid@chromium.org, May 18 2016

Not sure if older versions are better. I cannot practically bisect to find the CL because it is slow sometimes and faster sometimes.
Is there no way to find the cause of this by looking at the traces?

This time I also got a few log messages:
texture filtering.
[4526:4526:0517/171144:ERROR:gles2_cmd_decoder.cc(15078)] [.DisplayCompositor-0x150e48c08700]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[4526:4526:0517/171144:ERROR:gles2_cmd_decoder.cc(8222)] [.DisplayCompositor-0x150e48c08700]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[4526:4526:0517/171144:ERROR:gles2_cmd_decoder.cc(15078)] [.DisplayCompositor-0x150e48c08700]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[4526:4526:0517/171144:ERROR:gles2_cmd_decoder.cc(8222)] [.DisplayCompositor-0x150e48c08700]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.

Not sure if they are related.

Comment 9 by piman@chromium.org, May 18 2016

It looks like you are really close to the max GPU memory. When the GPU runs out of memory, it has to page in and out and that's slow. I think that's what's happening to you.

A couple of things:
- what does `nvidia-smi -q -d memory` say when chrome is not running?
- if you open the Chrome task manager (shift-escape) what does the "GPU memory" column say for the "GPU process" line? (you may need to enable that column by right-clicking on the task manager).
- I'm afraid to suggest it, but it's possible that restarting your desktop session, or even rebooting may help.
Labels: -Performance Performance-Loading
Status: Available (was: Untriaged)
Project Member

Comment 11 by sheriffbot@chromium.org, Apr 26 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)

Sign in to add a comment