Intermittent leakcheck | gpu process: X bytes leaked (APZCTreeManager::UpdateZoomConstraints, APZUpdater, APZUpdater::UpdateHitTestingTree, AsyncPanZoomController, CompositorManagerParent, ...)
Categories
(Core :: Graphics: WebRender, defect, P5)
Tracking
()
People
(Reporter: intermittent-bug-filer, Assigned: kats)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: intermittent-failure, regression, Whiteboard: [retriggered][gfx-noted])
Comment 1•6 years ago
|
||
Comment 3•6 years ago
|
||
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 6•6 years ago
|
||
Comment hidden (Intermittent Failures Robot) |
Comment 8•6 years ago
|
||
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 11•6 years ago
|
||
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Comment 12•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment 14•6 years ago
|
||
Assignee | ||
Comment 16•6 years ago
|
||
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 18•6 years ago
|
||
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 32•6 years ago
|
||
Updated•6 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 40•6 years ago
|
||
I started looking into this a bit. All the failures that I looked at have an APZUpdater::UpdateHitTestingTree leaked. Notably there is no corresponding APZUpdater::UpdateEpochRequirement leaked which is put into the updater queue just before. So this implies that the epoch requirement runnable is processed, which updates the epoch requirements. And those epoch requirements are never satisfied, leading to the UpdateHitTestingTree runnable never getting run. Subsequently on shutdown it is leaked along with everything it holds on to, which includes at least the APZUpdater and probably a bunch of other stuff.
At any rate, my plan of attack here is to try and figure out why the epoch requirement is not satisfied, and try and correct this leak, and then see if there are any more remaining leaked objects. I'll try reproducing locally on Linux with the GPU process enabled on a debug build, since rr would probably make debugging this a lot easier.
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 42•6 years ago
|
||
So yeah it looks like the WebRenderBridgeParent is destroyed between the UpdateHitTestingTree task getting queued and getting run. So then the epoch never updates and all the tasks in the queue for that layers id get leaked. I think there's an implicit assumption in the APZUpdater code that every epoch update (i.e. every non-empty transaction that comes over PWebRenderBridgeParent) will trigger a scene build, but I guess that's not the case. We should add a mechanism where the WRBP shutting down can tell the APZUpdater to discard or process all the remaining tasks for that layers id.
Assignee | ||
Comment 43•6 years ago
|
||
There's actually a bit more nuance to this. When the root WebRenderBridgeParent for a window is destroyed it flushes the scene builder queue, so any pending epoch updates and UpdateHitTestingTree tasks should get run. The APZUpdater code relies on this mechanism for clean shutdown.
Further investigation reveals that during the shutdown phase, it's possible for the parent process pipeline to get torn down while the content process is still sending display list updates. This causes the scene builder to go fail this check which then results in an "empty transaction" even though there was a new displaylist and epoch for the content pipeline. In this scenario, the pre/post swap hooks are not triggered, and so APZUpdater doesn't get the epoch update, and this results in the updated tasks getting leaked even when the scene builder thread is flushed.
So the correct fix here is to ensure that even in this "empty transaction" case (more specifically when there is no root pipeline) the APZUpdater gets an updated pipeline info and so runs pending tasks.
Assignee | ||
Comment 44•6 years ago
|
||
I think this "empty transaction" codepath was introduced by bug 1488887, so at least some of the leaks are a regression from that. However it looks like there was a slow trickle of instances of this bug even prior to that landing, so perhaps there are multiple causes. I'll put a fix for this issue in a dependent bug and we can see if this still happens after that lands.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 47•6 years ago
|
||
Looks like bug 1542800 fixed this.
Updated•3 years ago
|
Description
•