Issue metadata
Sign in to add a comment
|
BeginMainFrame hangs permanently mid-load on Granblue Fantasy quest/raid results pages
Reported by
k...@luminance.org,
Nov 27 2016
|
||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Example URL: http://game.granbluefantasy.jp/ (see comments) Steps to reproduce the problem: 1. Complete single-player or raid content in Granblue Fantasy 2. Observe the quest results page 3. If the browser didn't hang on the results page, keep playing... :-( What is the expected behavior? Content should load completely and the site should remain responsive. Worst case, if the page hangs/encounters an error the refresh button should work. What went wrong? Periodically (maybe a dozen times a day if I'm playing frequently), the tab process hangs part way through loading the results page. You see a partially rasterized version of the page and it is not responsive to input. Closing the tab using the 'x' doesn't work, and clicking the refresh button does nothing. Eventually you get the prompt to kill the tab. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? Yes Chrome 53, I think. I don't know exactly when this broke but it's a new (last week or so, maybe?) problem. Does this work in other browsers? N/A Chrome version: Version 54.0.2840.99 m (64-bit) Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 Sadly this is hard to bisect since any time I roll back to an old version of Chrome it instantly updates itself to the latest. This application doesn't work in Firefox or IE (it's intentionally Webkit/Blink only) so I can't compare there. When I inspect a hung process in visual studio, all the threads are waiting on objects, which matches with what Chrome's task manager says: 0% cpu usage. I have hardware acceleration turned off (because bugs in Chrome's hardware acceleration stack affect this game) so I don't think this is graphics related. The game is somewhat graphically intense, though. Attached screenshot of a hung process's stacks
,
Nov 27 2016
Not sure it will help, but a tab just hung this way while I was filing the report. Here's a recording from chrome://tracing (after the tab hung, unfortunately) Should I just leave tracing recording all the time in hopes of catching the moments leading up to a hang?
,
Nov 28 2016
,
Nov 28 2016
Yikes, this sounds terrible and also tough to track down. What's the typical play time until the hang? If you can manage to find something that reproduces the issue more quickly then we can bisect to try to find a culprit change. You can also try enabling logging (https://www.chromium.org/for-testers/enable-logging) and attaching the log near the time when the hang occurs. The fact that you've disabled hardware acceleration seems potentially relevant. Perhaps we can make better progress by debugging that issue. Can you please file a separate bug for whatever issues that occur with hardware acceleration enabled?
,
Nov 28 2016
There's also this advice for capturing process dumps when a hang occurs: https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs
,
Nov 28 2016
The interval varies some; yesterday I had it happen about 5 times in an hour. Other times it doesn't happen for a while. It only ever happens on that specific page, which is interesting. I tried turning hwaccel back on since it's been a little while; the related issues are all filed as bugs and I expect they'll be fixed eventually... might be fixed in 54, in fact. I'll try logging and the process dump stuff, thanks. The instructions say I have to disable the sandbox for logging to work, though - what is the impact of that on things like extensions and web workers?
,
Nov 28 2016
If you can provide the crash ids (server ids) from chrome://crashes we might be able to provide some context as to where the renderer process is hung. You will get a crash report send when you get the "hung renderer" dialog.
,
Nov 28 2016
Disabling the sandbox shouldn't cause anything to break but could put you at increased risk when browsing potentially malicious websites (though only if we have a security bug in the renderer). To mitigate the risk you might want to use an isolated instance of Chrome for this (--user-data-dir=c:/some-temp-path) to keep that higher risk session separate from any of your other uses of Chrome. I should note (for search purposes) that according to the provided callstacks the blink main thread is blocked on a WaitableEvent::Wait from within ProxyMain::BeginMainFrame. Presumably that's waiting for the impl thread to signal the completion event. dtapuska@ mentioned that a similar issue was fixed recently - we'll try to find the details.
,
Nov 28 2016
+vmpstr@ Seems very similar to issue 652884 which should have been fixed in 54.0.2840.59 so I don't know what is going on.
,
Nov 28 2016
,
Nov 28 2016
,
Nov 28 2016
,
Nov 28 2016
kg@luminance.org Can you please try running Chrome with the --disable-main-frame-before-activation flag? See this page for instructions for how to do so: https://www.chromium.org/for-testers/command-line-flags
,
Nov 30 2016
Here's a minidump for a hung tab. Same symptoms, and this is with hardware acceleration enabled, so that's ruled out as a factor. Stacks looked the same to me.
,
Dec 2 2016
Is it possible to get a trace before kind of before the hang happens and after it happens (in the same trace?) Also, are you a developer of this game? Is it possible to have a separate version of this game where we can just get to the problem screen without playing through the game? It's somewhat difficult to diagnose without a repro case...
,
Dec 2 2016
Alas I'm not a developer, and it's by a Japanese studio with no (AFAIK) means of contact.
,
Dec 12 2016
Thank you for providing more feedback. Adding requester "rbyers@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 12 2016
I honestly don't know what we can do about this. I'm assigning this to someone in the Tokyo office just to see if they can figure out who the developer is so we can get a repro. This also looks like a scheduling problem since we have everything hung waiting on some event that never occurs (I would have first expected JS loop, but that would generate some CPU load). Feel free to re-assign when we have some more info, or if no more info is available.
,
Dec 12 2016
The developer is Cygames: https://www.cygames.co.jp/en/ And the producer on Granblue Fantasy is (currently) Kimura Yuito: https://twitter.com/kimurayuito I don't know how you would get in touch with them, but they definitely have English-speaking staff since the game has an official English localization and one of their other titles (Shadowverse) is on the US Steam and Android stores. Incidentally I've heard from a couple people that this same 'quest results' screen crashes the webview app and/or Chrome on their Android phones periodically, so this could be a general problem with this particular content hitting an edge case that only fails sometimes.
,
Dec 12 2016
It isn't that we don't know what event it is waiting for... it is waiting for the completion event... aka stuck at this wait; https://cs.chromium.org/chromium/src/cc/trees/proxy_main.cc?q=BeginMainFrame&sq=package:chromium&l=240
,
Dec 12 2016
I forgot to mention, I didn't see this bug for a few days (after turning hwaccel back on), but then I got it again twice today. So it's just very intermittent, and not hw related at all... Going to switch my Chrome instance to running with --disable-main-frame-before-activation. Sadly the unpredictability means I might not be able to catch this with chrome://tracing, but I'll try.
,
Dec 12 2016
Sorry for the bug churn, I just noticed I left some identifying IDs in the original screenshots that shouldn't have been there... expected.png is what the results page looks like under normal circumstances, and when the process hangs it looks like the other two screenshots. The difference might be because the hung process's compositor is still partially functional (at least according to chrome://tracing), so it's able to present a partially rendered page?
,
Dec 12 2016
No one in Tokyo is familiar with this area.
,
Dec 13 2016
As a possible path forward, is it possible to save the html of the page that sometimes hangs? It's a long shot but maybe that's enough to reproduce the problem?
,
Dec 13 2016
Running with --disable-main-frame-before-activation, the hang appears to still happen periodically (at exactly the same spot), but it seems to recover after 2-5 seconds. Interesting. I tried to save the HTML after the hang but it appears 'save as' only saves what was initially sent over the network, so all the relevant HTML is missing.
,
Dec 14 2016
Somehow I was unable to reproduce the issue on reported version: 54.0.2840.99 on Windows-10. Played the game for 20 mins or so but didn't observe any hang as such. kg@: Would it be possible to have a sample repro case for consistent repro to try a bisect of this. Also, could you please try the same on the latest stable(55.0.2883.87) and confirm if the issue persists there as well?
,
Dec 17 2016
I captured the raw HTML of a results page that hung (though as mentioned before, it recovers eventually with --disable-main-frame-before-activation) and sadly it doesn't hang when reloaded. I used <base href> to make it load relative to the original URL, and all the relevant assets loaded (though I doubt the game code was running). It seems like this is some sort of timing issue or race condition. When it happens the hang is always roughly at the same spot in the page load/rasterization process (before the background on the modal has painted, but after the text has painted)
,
Dec 17 2016
I left chrome://tracing in record mode to try to capture it, but the resulting traces can't be loaded:
tracing.js:2074 RangeError: Inflated gzip data too long to fit into a string (429329125).
at Function.GzipImporter.inflateGzipData_ (tracing.js:4825)
at GzipImporter.extractSubtraces (tracing.js:4829)
at Import.createImports (tracing.js:1343)
at Task.run (tracing.js:2062)
at runAnother (tracing.js:2074)
at runTask (tracing.js:2037)
at processIdleWork (tracing.js:2043)
at window.requestIdleCallback.timeout (tracing.js:2031)
,
Dec 26 2016
Thank you for providing more feedback. Adding requester "ajha@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 28 2016
Requesting for further inputs on this from Devs in Cc list.
,
Jan 2 2017
Don't have access to the machine I originally made this report from, but the bug never reoccurred after I added the flag. Furthermore, after playing some on another PC I own (Microsoft Surface Book, using release Chrome) the bug occurs sometimes in exactly the same way, so it doesn't seem to be machine-specific.
,
Jan 4 2017
Friendly ping!! Could anybody from Devs in Cc list, please update the thread on the same as per Comment#31. Thank you.
,
Jan 4 2017
@29, is there any way you can start a trace shortly before the the page that has the hang to try and reduce the size of it? Also, you can try only enabling cc category to try and reduce the size of it? Do you have an option to save the trace even if the loading fails? If so can you attach it here?
,
Jan 4 2017
I just hit the same type of issue, but I have an option to save the trace anyway. Could you attach that if it happens? I think we can split the trace into several loadable components to see if we can figure out what the problem is.
,
Jan 5 2017
I've also added a flag --check-tile-priority-inversion which is now in the canary build (initially in 57.0.2972.0), could you try playing the game/reproducing the problem with that flag enabled to see if causes a CHECK failure
,
Jan 5 2017
(you would have to launch Canary chrome with that custom flag specified)
,
Jan 11 2017
,
Jan 11 2017
Will the CHECK failure manifest as a crash or will I need to be running chromium with a console or logging enabled?
,
Jan 11 2017
A check will crash the renderer, and it should then appear in chrome://crashes so that we can find the report.
,
Jan 16 2017
Removing the Needs-Bisect and Needs-TestConfirmation label as the issue is not reproducible from TE's end per C#27. Feel free to add the labels back if this requires any further testing or requires bisect with reproducible test case. kg@: Please let us know if any crash id was generated under chrome://crashes.
,
Jan 23 2017
Hi kg@, could you let us know if you were able to get a crash? Thanks!
,
Jan 23 2017
I completely forgot to test this. I can confirm that I haven't seen the bug since setting --disable-main-frame-before-activation, though. I'll turn on the check flag. Should I remove disable-main-frame so the check will work?
,
Jan 23 2017
Yes please.
,
Jan 27 2017
I have no way to know whether this is from the tile priority inversion check, but I got a tab crash while playing today: Crash ID c75c88c8-e9b7-432f-afab-b553aa3aa07b (Server ID: 544efc1580000000) Crash report captured on Thursday, January 26, 2017 at 5:31:53 PM, uploaded on Thursday, January 26, 2017 at 5:32:01 PM
,
Jan 27 2017
It is, thanks. 0x00007ffd981b44ce (chrome_child.dll -tile_manager.cc:759 ) cc::TileManager::AssignGpuMemoryToTiles() 0x00007ffd97a88b1c (chrome_child.dll -tile_manager.cc:495 ) cc::TileManager::PrepareTiles(cc::GlobalStateThatImpactsTilePriority const &) 0x00007ffd97a886c1 (chrome_child.dll -layer_tree_host_impl.cc:514 ) cc::LayerTreeHostImpl::PrepareTiles() 0x00007ffd9784737b (chrome_child.dll -layer_tree_host_impl.cc:385 ) cc::LayerTreeHostImpl::CommitComplete() 0x00007ffd9784728d (chrome_child.dll -proxy_impl.cc:516 ) cc::ProxyImpl::ScheduledActionCommit() 0x00007ffd9776c901 (chrome_child.dll -scheduler.cc:614 ) cc::Scheduler::ProcessScheduledActions() 0x00007ffd97b8f7fb (chrome_child.dll -scheduler.cc:161 ) cc::Scheduler::NotifyReadyToCommit() Crashed here: 759 vmpstr 23 days CHECK(!tile->required_for_activation()) 760 vmpstr 23 days << "mode: " << global_state_.tree_priority 761 vmpstr 23 days << " bin: " << priority.priority_bin 762 vmpstr 23 days << " highest bin: " << highest_bin_found;
,
Jan 28 2017
Here's another one Crash ID ebca47dc-d8a8-4d37-be19-bb9d3a5813be (Server ID: 667de02880000000) I'll stop pasting them here unless you want to continue to collect them to compare for common details.
,
Jan 30 2017
Huh, well that appears to be something unrelated - a crash in v8.
,
Jan 30 2017
In case it's helpful, here's all the other crashes I got while playing in Canary for a day or so. Eventually it became impossible to tolerate so I switched back to using Release. ---- Crash ID a8316a32-670e-4377-9f30-6983f55019d0 (Server ID: ab2c7e1580000000) Crash report captured on Saturday, January 28, 2017 at 6:06:18 AM, uploaded on Saturday, January 28, 2017 at 6:07:34 AM Provide additional details Crash ID a08351cf-7826-46dd-a91d-2ed721ffc2c7 (Server ID: 024f4ca680000000) Crash report captured on Saturday, January 28, 2017 at 6:05:17 AM, uploaded on Saturday, January 28, 2017 at 6:07:32 AM Provide additional details Crash ID 7087b2b3-d9a4-462b-a6a0-dad1cd6a2add (Server ID: 23402ca680000000) Crash report captured on Saturday, January 28, 2017 at 5:59:55 AM, uploaded on Saturday, January 28, 2017 at 6:07:31 AM Provide additional details Crash ID 448838bd-f80d-48f8-af7b-4d813c7f0414 (Server ID: 8429d82880000000) Crash report captured on Saturday, January 28, 2017 at 5:58:53 AM, uploaded on Saturday, January 28, 2017 at 6:07:30 AM Provide additional details Crash ID da3f36af-a042-46ab-8d3f-a2373b40ea08 (Server ID: d3d7be1580000000) Crash report captured on Saturday, January 28, 2017 at 5:58:09 AM, uploaded on Saturday, January 28, 2017 at 5:58:56 AM Provide additional details Crash ID 68a50566-0559-4097-b29d-a367ba208a1f (Server ID: 19ac582880000000) Crash report captured on Saturday, January 28, 2017 at 5:57:58 AM, uploaded on Saturday, January 28, 2017 at 5:58:54 AM Provide additional details Crash ID 7333c151-95b4-4cd3-9a3a-e8fa96fa92cd (Server ID: c1a07e1580000000) Crash report captured on Saturday, January 28, 2017 at 5:57:04 AM, uploaded on Saturday, January 28, 2017 at 5:58:00 AM Provide additional details Crash ID 44011e60-9a1b-4da0-8b3b-d2015b526401 (Server ID: ab3fbe1580000000) Crash report captured on Saturday, January 28, 2017 at 5:55:55 AM, uploaded on Saturday, January 28, 2017 at 5:57:59 AM Provide additional details Crash ID 2bf67a94-33f2-4354-aea2-5f51fdb0a576 (Server ID: 818c0ca680000000) Crash report captured on Saturday, January 28, 2017 at 5:54:34 AM, uploaded on Saturday, January 28, 2017 at 5:56:02 AM Provide additional details Crash ID 8c7e1f17-9770-4cd2-83c4-8662f19fa763 (Server ID: 04fa982880000000) Crash report captured on Saturday, January 28, 2017 at 5:53:33 AM, uploaded on Saturday, January 28, 2017 at 5:56:01 AM Provide additional details Crash ID b35474dd-1571-4bdc-82ac-fc79278792dc (Server ID: 8c88582880000000) Crash report captured on Saturday, January 28, 2017 at 5:52:11 AM, uploaded on Saturday, January 28, 2017 at 5:56:00 AM Provide additional details Crash ID 4fc28b55-c53c-4b12-8057-9c857a8936c2 (Server ID: b62b982880000000) Crash report captured on Saturday, January 28, 2017 at 5:43:52 AM, uploaded on Saturday, January 28, 2017 at 5:55:59 AM Provide additional details Crash ID a13a7cb1-5da6-4c7d-87b3-b1162113ad6c (Server ID: 0dd0982880000000) Crash report captured on Saturday, January 28, 2017 at 5:38:17 AM, uploaded on Saturday, January 28, 2017 at 5:55:58 AM Provide additional details Crash ID 40657ddb-e039-4442-b6ee-f85c9ee638fd (Server ID: 3a03e4a680000000) Crash report captured on Saturday, January 28, 2017 at 5:34:16 AM, uploaded on Saturday, January 28, 2017 at 5:34:17 AM Provide additional details Crash ID 860728c4-e012-4b11-807b-9b7301a00d3b (Server ID: c4f7be1580000000) Crash report captured on Saturday, January 28, 2017 at 3:02:21 AM, uploaded on Saturday, January 28, 2017 at 5:55:56 AM Provide additional details
,
Jan 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a062f034b9c367a0b3481e0390bcc0aca830b707 commit a062f034b9c367a0b3481e0390bcc0aca830b707 Author: vmpstr <vmpstr@chromium.org> Date: Tue Jan 31 19:21:58 2017 cc: Fix tile priority inversion in picture layer tiling. This patch addresses the case where we can have a tile that is required for activation but is not in the NOW bin. This can happen since the check for whether the tile is required uses the tile's content_rect, which includes border pixels. However, the priority calculation for the tile uses TileBounds without the border pixels. This patch also moves the code to calculate required tile state from all of the different iterator call sites to MakePrioritizedTile, with an additional check to ensure that we never make a required tile outside of the now bin. R=danakj@chromium.org BUG= 668892 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2651413004 Cr-Commit-Position: refs/heads/master@{#447293} [modify] https://crrev.com/a062f034b9c367a0b3481e0390bcc0aca830b707/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/a062f034b9c367a0b3481e0390bcc0aca830b707/cc/tiles/picture_layer_tiling.h [modify] https://crrev.com/a062f034b9c367a0b3481e0390bcc0aca830b707/cc/tiles/picture_layer_tiling_unittest.cc [modify] https://crrev.com/a062f034b9c367a0b3481e0390bcc0aca830b707/cc/tiles/tiling_set_eviction_queue.cc [modify] https://crrev.com/a062f034b9c367a0b3481e0390bcc0aca830b707/cc/tiles/tiling_set_raster_queue_all.cc [modify] https://crrev.com/a062f034b9c367a0b3481e0390bcc0aca830b707/cc/tiles/tiling_set_raster_queue_required.cc
,
Jan 31 2017
A lot of those crashes seem to be due to crbug.com/685680 (which semms to be fixed now). With this bug, I think we found the problem and fixed it in #50, which should make it to Canary by tomorrow (I'll update the bug with the version that will have it).
,
Feb 1 2017
The fix should be in 58.0.2999.0, which is in Canary. I'm going to optimistically close this as fixed. Please re-open if the problem persists.
,
Feb 21 2017
Seems that there are a few hangs that are fixed by this, so I'm going to request a merge for the patch in #50.
,
Feb 21 2017
Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/050a3b4e60535623b42101cc4e269c077da721c7 commit 050a3b4e60535623b42101cc4e269c077da721c7 Author: Vladimir Levin <vmpstr@chromium.org> Date: Tue Feb 21 20:16:12 2017 cc: Fix tile priority inversion in picture layer tiling. This patch addresses the case where we can have a tile that is required for activation but is not in the NOW bin. This can happen since the check for whether the tile is required uses the tile's content_rect, which includes border pixels. However, the priority calculation for the tile uses TileBounds without the border pixels. This patch also moves the code to calculate required tile state from all of the different iterator call sites to MakePrioritizedTile, with an additional check to ensure that we never make a required tile outside of the now bin. R=danakj@chromium.org BUG= 668892 , 622080 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2651413004 Cr-Commit-Position: refs/heads/master@{#447293} (cherry picked from commit a062f034b9c367a0b3481e0390bcc0aca830b707) Review-Url: https://codereview.chromium.org/2711573002 . Cr-Commit-Position: refs/branch-heads/2987@{#620} Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943} [modify] https://crrev.com/050a3b4e60535623b42101cc4e269c077da721c7/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/050a3b4e60535623b42101cc4e269c077da721c7/cc/tiles/picture_layer_tiling.h [modify] https://crrev.com/050a3b4e60535623b42101cc4e269c077da721c7/cc/tiles/picture_layer_tiling_unittest.cc [modify] https://crrev.com/050a3b4e60535623b42101cc4e269c077da721c7/cc/tiles/tiling_set_eviction_queue.cc [modify] https://crrev.com/050a3b4e60535623b42101cc4e269c077da721c7/cc/tiles/tiling_set_raster_queue_all.cc [modify] https://crrev.com/050a3b4e60535623b42101cc4e269c077da721c7/cc/tiles/tiling_set_raster_queue_required.cc
,
Mar 2 2017
kg@luminance.org this should no longer be possible to reproduce, with or without the command line flag, in canary or beta. Would you be able to confirm if that is the case for us?
,
Mar 3 2017
I've been running 56 on my new PC for a while without the command line flags and haven't hit the bug recently. It's possible the game's content was changed in such a way that the bug doesn't occur anymore. If I manage to hit the bug again in release channel I can try to verify that it is gone in beta/canary.
,
Mar 3 2017
Ok thanks!
,
Apr 11 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c7d72f32028bc11312db3d9604e3a70da73168b7 commit c7d72f32028bc11312db3d9604e3a70da73168b7 Author: sunnyps <sunnyps@chromium.org> Date: Tue Apr 11 19:07:50 2017 cc: Dump scheduler and tile manager state when commit is blocked. This adds a DumpWithoutCrashing call that's posted from the main thread to the impl thread. This is done after a 20s timeout which is chosen to be less than the renderer hung timeout (30s) but still large enough. The crash dump includes scheduler and tile manager state on the stack. R=vmpstr@chromium.org BUG= 668892 ,622080 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2790173005 Cr-Commit-Position: refs/heads/master@{#463711} [modify] https://crrev.com/c7d72f32028bc11312db3d9604e3a70da73168b7/cc/base/completion_event.h [modify] https://crrev.com/c7d72f32028bc11312db3d9604e3a70da73168b7/cc/trees/proxy_impl.cc [modify] https://crrev.com/c7d72f32028bc11312db3d9604e3a70da73168b7/cc/trees/proxy_impl.h [modify] https://crrev.com/c7d72f32028bc11312db3d9604e3a70da73168b7/cc/trees/proxy_main.cc
,
Apr 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/73f0465777d91348d35874b5d2ebd28e5dfff138 commit 73f0465777d91348d35874b5d2ebd28e5dfff138 Author: sunnyps <sunnyps@chromium.org> Date: Sat Apr 15 01:46:45 2017 cc: Add more info to the BeginMainFrame dump. Add more info to determine if scheduler dropped frames. Change the dump string to be proper JSON and increases the size to 50k. Make begin frame source code compliant with the style guide. R=brianderson BUG= 668892 ,622080 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2819723002 Cr-Commit-Position: refs/heads/master@{#464849} [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/scheduler/begin_frame_source.cc [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/scheduler/begin_frame_source.h [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/scheduler/scheduler.cc [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/scheduler/scheduler.h [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/scheduler/scheduler_state_machine.cc [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/tiles/tile_manager.cc [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/tiles/tile_manager.h [modify] https://crrev.com/73f0465777d91348d35874b5d2ebd28e5dfff138/cc/trees/proxy_impl.cc
,
Apr 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd1281da74251c1116fad952dc794a107e5ba1e3 commit bd1281da74251c1116fad952dc794a107e5ba1e3 Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Thu Apr 20 00:20:33 2017 cc: Add deadline timestamps to scheduler dump. The BeginMainFrame hang dumps say that the deadline isn't being run for a long time. This CL adds the timestamps of the deadline and when the deadline was scheduled. This also adds a couple of missing impl side activation properties in the state machine dump and changes a couple of begin frame tracker timestamps to be in milliseconds. See the following dumps for example: https://gist.github.com/sunnyps/9ed1665f8f078df197d05d3300ce3f19 https://gist.github.com/sunnyps/ee3111514c231cde27003f6486ad6c6f R=vmpstr BUG= 668892 , 622080 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Change-Id: I7808928a484e0786c1eca76f8c60afbf231ad1f6 Reviewed-on: https://chromium-review.googlesource.com/482539 Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Reviewed-by: Vladimir Levin <vmpstr@chromium.org> Cr-Commit-Position: refs/heads/master@{#465820} [modify] https://crrev.com/bd1281da74251c1116fad952dc794a107e5ba1e3/cc/scheduler/begin_frame_tracker.cc [modify] https://crrev.com/bd1281da74251c1116fad952dc794a107e5ba1e3/cc/scheduler/scheduler.cc [modify] https://crrev.com/bd1281da74251c1116fad952dc794a107e5ba1e3/cc/scheduler/scheduler.h [modify] https://crrev.com/bd1281da74251c1116fad952dc794a107e5ba1e3/cc/scheduler/scheduler_state_machine.cc
,
Apr 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/40f1892ad93b2dc497141e351fddf32475b8cd62 commit 40f1892ad93b2dc497141e351fddf32475b8cd62 Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Fri Apr 21 21:10:53 2017 cc: Remove slow BeginMainFrame dump. This is for M59 branch only. We'd like to keep the dump for canary but we need to land it on trunk, ship in one canary, merge to branch, and then revert on trunk. R=vmpstr BUG= 668892 , 622080, 711064 Change-Id: I78031639da8ac09925e080b6af342e075909bafb CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Change-Id: I78031639da8ac09925e080b6af342e075909bafb Reviewed-on: https://chromium-review.googlesource.com/484703 Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Reviewed-by: Vladimir Levin <vmpstr@chromium.org> Cr-Commit-Position: refs/heads/master@{#466444} [modify] https://crrev.com/40f1892ad93b2dc497141e351fddf32475b8cd62/cc/trees/proxy_main.cc
,
Apr 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8ee798628e7bc80a2f60da06b710f251ea89ee3e commit 8ee798628e7bc80a2f60da06b710f251ea89ee3e Author: Sunny Sachanandani <sunnyps@chromium.org> Date: Mon Apr 24 18:35:05 2017 cc: Remove slow BeginMainFrame dump. This is for M59 branch only. We'd like to keep the dump for canary but we need to land it on trunk, ship in one canary, merge to branch, and then revert on trunk. R=vmpstr BUG= 668892 , 622080, 711064 Change-Id: I78031639da8ac09925e080b6af342e075909bafb CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Change-Id: I78031639da8ac09925e080b6af342e075909bafb Reviewed-on: https://chromium-review.googlesource.com/484703 Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Reviewed-by: Vladimir Levin <vmpstr@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#466444}(cherry picked from commit 40f1892ad93b2dc497141e351fddf32475b8cd62) Review-Url: https://codereview.chromium.org/2843433003 . Cr-Commit-Position: refs/branch-heads/3071@{#171} Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641} [modify] https://crrev.com/8ee798628e7bc80a2f60da06b710f251ea89ee3e/cc/trees/proxy_main.cc
,
May 23 2017
sunnyps@, Please mark it as 'Fixed' if no other CL is pending. Thank you!
,
Jun 26 2017
sunnyps@, is there more to do here?
,
Nov 17 2017
Seems like this was reopened only for the merge. Closing as Fixed like before. Issue 622080 is tracking BeginMainFrame hangs in general.
,
Feb 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/354841bbca5aa1e389725c8cf1f4c509b8dc0d89 commit 354841bbca5aa1e389725c8cf1f4c509b8dc0d89 Author: Sadrul Habib Chowdhury <sadrul@chromium.org> Date: Fri Feb 23 09:42:22 2018 cc: Remove some dead code. The usage of DumpForBeginMainFrameHang() was removed in crrev.com/466444 in Apr 2017. So remove this now-unused debug function. BUG= 668892 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Change-Id: Iff9f8d928d3f09e43e56e54df0c48ba907656bb3 Reviewed-on: https://chromium-review.googlesource.com/927922 Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org> Cr-Commit-Position: refs/heads/master@{#538738} [modify] https://crrev.com/354841bbca5aa1e389725c8cf1f4c509b8dc0d89/cc/trees/proxy_impl.cc [modify] https://crrev.com/354841bbca5aa1e389725c8cf1f4c509b8dc0d89/cc/trees/proxy_impl.h
,
Feb 26 2018
Unable to reproduce this issue on reported version as per comment#27, 41 from TE End. Hence it would not be possible to verify the fix on latest canary 66.0.3355.0 from TE end. @sadrul: Please help us in verifying the fix. Thanks! |
|||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||
Comment 1 Deleted