Issue metadata
Sign in to add a comment
|
inbox/hangouts get stuck using 100% of a core in the backgounrd |
||||||||||||||||||||||||
Issue descriptionI keep finding Inbox using 100% of a core while in a background tab. Whenever this happens, all the Inbox tabs I have open each use a core. If I focus Inbox for a few seconds, then switch to another tab, it calms down. I'm attaching traces, but all they show is that there's a large number of main thread tasks running through the TaskQueueManager. I couldn't get a trace of the renderer.scheduler category because tracking crashes, but I got all the others. The only non-default flag I have set is the #pause-background-tabs one. So this definitely could be some weird interaction there. I can't get to devtools to see what's running without focusing the tab and causing the bug to go away. I'll try leaving devtools open from now on in a different window so I can gather more information when it happens. Other suggestions welcome. I guess I should pull out Instruments and actually hook it up to debug symbols. I wish that were easier. :(
,
Apr 21 2017
Here's a screenshot of an Instruments trace. There's something involving MessagePorts. My guess is that postMessages from a worker are building up or something like that and we keep trying to deliver them. The pause-background-tabs flag causes us to hit https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc?q=renderer_scheduler_imp+package:%5Echromium$&l=1115. I realize now I don't have a full grasp of what disabling the timer queue does. Does it disable them in all frames/workers or just the main frame or all frames and no workers? But, even then, when I measured with devtools, I didn't see any JS running. I'm not sure quite how to dig into this further. Suggestions welcome. I'll at least try turning off the flag and seeing if the bug goes away. Seems like one of the following is happening: 1. The pause-background-tabs flag doing something strange on desktop that it doesn't do on mobile for some reason. 2. The mobile behavior also has this bug. 3. A postMessage/MessagePort change caused a bug. I know Darin recently refactored.
,
Apr 21 2017
I got a Chrome update and this seems like it stopped happening. So, I'm going to assume this was related to recent MessagePort refactor unless it happens again. Will reopen if it happens again.
,
Apr 24 2017
Yeah looks like MessagePort was doing something crazy here. Closing as per #3.
,
May 4 2017
Nope. It's still happening. :( I'm not really sure how to diagnose given that I don't have easy repro steps. Will assign to myself for now though.
,
May 5 2017
,
Aug 15 2017
I keep hitting issues with hangouts.google.com and inbox.google.com (with chat disabled) where they use 100% CPU in a background tab. If I focus the tab and then background it again, the CPU drops back down to a normal Hangouts/Inbox tab. I'm on 62.0.3182.0 (Official Build) canary (64-bit) on "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3182.0 Safari/537.36" I have a trace with the whole left column and the renderer_scheduler, renderer_scheduler.debug, worker_scheduler, worker_scheduler.debug categories all selected. I don't see anything useful in the trace though. Not sure what else I can search for. I believe I don't have any custom flags enabled. Here are my finch variations though: c04e5123-cf4f6ead 16e0dd70-3f4a17df c68ab9a3-6edc92c7 b130ecb8-2e32ee7e 6025934e-3f4a17df 7c1bc906-ff96eb58 ce38b0fc-3f4a17df 47e5d3db-3d47f4f4 2a33b90e-48ba8004 1c752ce9-ca7d8d80 776de70c-e0278d3d 79616653-3f4a17df 83cae636-f23d1dea 5ca89f9-f23d1dea c447111e-d93a0620 6c7c7e88-f23d1dea ed7ba060-f23d1dea 9e201a2b-65bced95 bf476a9a-3f4a17df 57f575bb-f23d1dea 68812885-f23d1dea 332a4d9b-e4165b4e 684d1cdf-adb28e02 85bd8b7e-6e910a71 f347910c-65bced95 b791c1b8-f23d1dea 9773d3bd-803f8fc4 99144bc3-3f4a17df cd1a8f9-870290a7 1e629577-f23d1dea 165e16d1-3f4a17df 9e5c75f1-3c439a48 8ef0eb0f-7e93edd 350fabdd-1cf80f06 f79cb77b-3f4a17df be3b5415-bed9585 d6e92b97-788830cb 27219e67-b2047178 23a898eb-3f2db5fb 4ea303a6-5deff412 d92562a9-97fcc22f de03e059-e65e20f2 1bced4a3-7f989603 ad6d27cc-3e870323 f56e0452-f23d1dea b2f0086-192df033 ef25c1eb-3f4a17df 344833e9-1525b35b 3f273a97-25a103a9 4bc337ce-223ed323 1354da85-af932c1d 494d8760-1410f10 3ac60855-3ec2a267 f296190c-d0fe63d6 4442aae2-6bdfffe7 ed1d377-e1cc0f14 75f0f0a0-a5822863 e2b18481-6e597ede e7e71889-e1cc0f14 f5fff3a2-f23d1dea d1c43657-f23d1dea 8db050d4-956ce709 11d91db8-3f4a17df 828a5926-8f2c913 81c6897f-2d9ebb2e da4aaa01-f23d1dea
,
Aug 15 2017
whoops, here's the trace
,
Aug 15 2017
RangeError: Inflated gzip data too long to fit into a string (457240664) :( I think we need to manually trim this trace a bit...
,
Aug 21 2017
There was a recent regression that impacted the canary builds - see crbug/756311 that is now resolved. I am not sure about the original issue, reported on April 20th 2017. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ojan@chromium.org
, Apr 20 2017