-
Notifications
You must be signed in to change notification settings - Fork 297
Fix cache synchronization crash with blob images. #3378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
On the first pass of prepare_transaction: 1) Resource update contains only an AddBlobImage, but it is not visible according to viewport_tiles (set in SetBlobImageVisibleArea) 2) We call ResourceCache::create_blob_scene_builder_requests but since the image is not visible, it doesn't create any BlobImageParams entries (containing the blob image key) to be stored in txn.blob_requests 3) Since the transaction has no blob image updates, we can take the shortcut to call RenderBackend::update_document directly 4) We didn't call ResourceCache::set_blob_rasterizer with the updated txn.blob_rasterizer. On the second pass of prepare_transaction: 1) Resource update contains only an SetBlobImageVisibleArea 2) We don't call ResourceCache::create_blob_scene_builder_requests since there is no Add/UpdateBlobImage entries. 3) Since the transaction has no blob image updates, we can take the shortcut to call RenderBackend::update_document directly 4) We are missing the blob we added in the previous step in ResourceCache::request_image, and it adds it to missing_blob_images. 5) We try to process missing_blob_images in ResourceCache::rasterize_missing_blob_images with the old blob_rasterizer. 6) Crash. Potentially fixes bug 1492241.
@kvark review? also can you retrigger the failing taskcluster job? Looks like it was an internal error, but it won't accept my auth token for the retrigger... |
Does this require an empty visible area to trigger?
|
I believe this is safe to merge, especially given that we came up with this change rationally, and the try is green. 🤞 for the crash to be resolved |
📌 Commit f2b96de has been approved by |
Fix cache synchronization crash with blob images. On the first pass of prepare_transaction: 1) Resource update contains only an AddBlobImage, but it is not visible according to viewport_tiles (set in SetBlobImageVisibleArea) 2) We call ResourceCache::create_blob_scene_builder_requests but since the image is not visible, it doesn't create any BlobImageParams entries (containing the blob image key) to be stored in txn.blob_requests 3) Since the transaction has no blob image updates, we can take the shortcut to call RenderBackend::update_document directly 4) We didn't call ResourceCache::set_blob_rasterizer with the updated txn.blob_rasterizer. On the second pass of prepare_transaction: 1) Resource update contains only an SetBlobImageVisibleArea 2) We don't call ResourceCache::create_blob_scene_builder_requests since there is no Add/UpdateBlobImage entries. 3) Since the transaction has no blob image updates, we can take the shortcut to call RenderBackend::update_document directly 4) We are missing the blob we added in the previous step in ResourceCache::request_image, and it adds it to missing_blob_images. 5) We try to process missing_blob_images in ResourceCache::rasterize_missing_blob_images with the old blob_rasterizer. 6) Crash. Potentially fixes bug 1492241. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/3378) <!-- Reviewable:end -->
Here's a try to find empty rects: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9484bdaa41dbb0b0a328ee605fd41d712349ef99 |
☀️ Test successful - status-appveyor, status-taskcluster |
…136e96c786b5 (WR PR #3378). r=kats servo/webrender#3378 Differential Revision: https://phabricator.services.mozilla.com/D13629 --HG-- extra : moz-landing-system : lando
…136e96c786b5 (WR PR #3378). r=kats servo/webrender#3378 Differential Revision: https://phabricator.services.mozilla.com/D13629
Isn't it possible that there is a slow scene build in progress when this code runs? When that scene build finishes, it will set the blob rasterizer again, to one that was created before this? |
Pass AsyncImageBlobRasterizer through the stack explicitly Similar to #3378, this PR attempts to address our failures in bug 1492241. If we aren't sure that the blob image rasterizer, being a state of the resource cache, is the right one to build the scene, then perhaps it shouldn't be a state in the first place. This is what this PR is doing. It's not guaranteed to fix anything, just bringing more clarity to the code, hopefully helping us to rule out one of the possible causes. r? @nical cc @aosmond Gecko try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=726e01545625a20153893dbb22509b70294651bb <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/3382) <!-- Reviewable:end -->
…136e96c786b5 (WR PR #3378). r=kats servo/webrender#3378 Differential Revision: https://phabricator.services.mozilla.com/D13629 UltraBlame original commit: 1ff8628621d03f4dc89d8b098208bbf2ecc9e479
…136e96c786b5 (WR PR #3378). r=kats servo/webrender#3378 Differential Revision: https://phabricator.services.mozilla.com/D13629 UltraBlame original commit: 1ff8628621d03f4dc89d8b098208bbf2ecc9e479
…136e96c786b5 (WR PR #3378). r=kats servo/webrender#3378 Differential Revision: https://phabricator.services.mozilla.com/D13629 UltraBlame original commit: 1ff8628621d03f4dc89d8b098208bbf2ecc9e479
On the first pass of prepare_transaction:
On the second pass of prepare_transaction:
Potentially fixes bug 1492241.
This change is