Closed Bug 1450162 Opened 7 years ago Closed 7 years ago

Crash in mozalloc_abort | abort | _$LT$webrender_bindings..moz2d_renderer..Moz2dImageRenderer$u20$as$u20$webrender_api..image..BlobImageRenderer$GT$::update::h24630926a4127e2a

Categories

(Core :: Graphics: WebRender, defect, P2)

x86_64
All
defect

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 --- disabled

People

(Reporter: jan, Assigned: jrmuizel)

References

(Blocks 1 open bug)

Details

(Keywords: crash, nightly-community)

Crash Data

Attachments

(3 files)

Seen on Socorro. One crash (so far). bp-8b51fdde-1600-4b61-8b39-1a1c00180329 build 2018-03-28_141001 MacOS > Unexpectedly empty result. This blob should just have been deleted This crash reason was introduced by bug 1388842. The wording triggered me to file this bug.
Flags: needinfo?(jan)
found on about:crashes: bp-3b952fe3-1629-42d5-81ff-67f7a0180331 build 2018-03-31_101347 (main profile: gfx.webrender.blob.invalidation;true etc.) [@ mozalloc_abort | abort | libxul.so@0x3d6c728 | libxul.so@0x3d6c718 | libxul.so@0x3d5c270 | webrender_bindings::moz2d_renderer::{{impl}}::update ] > Unexpectedly empty result. This blob should just have been deleted
Crash Signature: [@ mozalloc_abort | abort | _$LT$webrender_bindings..moz2d_renderer..Moz2dImageRenderer$u20$as$u20$webrender_api..image..BlobImageRenderer$GT$::update::h24630926a4127e2a ] → [@ mozalloc_abort | abort | _$LT$webrender_bindings..moz2d_renderer..Moz2dImageRenderer$u20$as$u20$webrender_api..image..BlobImageRenderer$GT$::update::h24630926a4127e2a ] [@ mozalloc_abort | abort | libxul.so@0x3d69b08 | libxul.so@0x3d69af8 | libxul.so@…
OS: Mac OS X → All
Attached video 2018-04-03_22-37-34.mp4
Nightly 61 x64 20180403100105 de_DE 4a3275936ddf871103b53e00608e2b8d5aee7e69 @ Debian Testing, KDE, Radeon RX480, 2560x1440 fresh profile: gfx.webrender.all + gfx.webrender.blob.invalidation So far I couldn't reproduce with gfx.webrender.blob.invalidation;false (default). http://www.spiegel.de/wirtschaft/soziales/hartz-iv-grosse-mehrheit-will-grundsaetzliche-aenderung-beim-arbeitslosengeld-ii-a-1201002.html bp-d9873ab9-9274-4277-a138-3dde20180403 [@ mozalloc_abort | abort | libxul.so@0x3d69b08 | libxul.so@0x3d69af8 | libxul.so@0x3d59650 | libxul.so@0x3d59495 | libxul.so@0x3d59429 | webrender_bindings::moz2d_renderer::{{impl}}::update ] > MOZ_CRASH Reason assertion failed: `(left == right)`
I was able to reproduce this.
Assignee: nobody → jmuizelaar
Thanks for finding steps to do so.
Crash Signature: [@ mozalloc_abort | abort | _$LT$webrender_bindings..moz2d_renderer..Moz2dImageRenderer$u20$as$u20$webrender_api..image..BlobImageRenderer$GT$::update::h24630926a4127e2a ] [@ mozalloc_abort | abort | libxul.so@0x3d69b08 | libxul.so@0x3d69af8 | libxul.so@… → [@ mozalloc_abort | abort | _$LT$webrender_bindings..moz2d_renderer..Moz2dImageRenderer$u20$as$u20$webrender_api..image..BlobImageRenderer$GT$::update::h24630926a4127e2a ] [@ mozalloc_abort | abort | _$LT$webrender_bindings..moz2d_renderer..Moz2dImageRen…
It looks like display items are being reordered without us including them invalid area.
I have an rr recording of this happening. While stepping through it realized that it might be possible for this reordering to happen when using retained display lists. The current blob merging code has an assumption that this won't happen.
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #3) > Created attachment 8964693 [details] gfx.webrender.all;true = good gfx.webrender.all;true + gfx.webrender.blob.invalidation;true = visual bug + crash gfx.webrender.all;true + gfx.webrender.blob.invalidation;true + layout.display-list.retain;false = visual bug + no crash In the video you can see that sometimes when hovering over the diagram the appearing box has a thicker border/shadow for a moment. (blob invalidation bug)
See Also: → 1451458
Crash Signature: webrender_bindings::moz2d_renderer::{{impl}}::update ] → webrender_bindings::moz2d_renderer::{{impl}}::update ] [@ mozalloc_abort | abort | libxul.so@0x3d67ac8 | libxul.so@0x3d67ab8 | libxul.so@0x3d57610 | webrender_bindings::moz2d_renderer::{{impl}}::update ]
Comment on attachment 8965098 [details] Bug 1450162. Correctly merge in the presence of reorderings. https://reviewboard.mozilla.org/r/233798/#review239478 r+ once the logic is rewritten to look more like https://pastebin.mozilla.org/9082275 . ::: gfx/webrender_bindings/src/moz2d_renderer.rs:267 (Diff revision 1) > + // We use a BTree as a kind of multi-map by appending cache_order to the key > + // this lets us multiple items with matching bounds in the map and allows > + // us to fetch and remove them while retaining the ordering of the original list Make this: // We use a BTree as a kind of multi-map, by appending an integer "cache_order" to the key. // This lets us use multiple items with matching bounds in the map and allows // us to fetch and remove them while retaining the ordering of the original list. There was a missing "use" in there.
Attachment #8965098 - Flags: review?(mstange) → review+
Comment on attachment 8965097 [details] Bug 1450162. Add a crash test that invalidates our previous assumptions. https://reviewboard.mozilla.org/r/233796/#review239480
Attachment #8965097 - Flags: review?(mstange) → review+
Pushed by jmuizelaar@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6f967d0a02df Use an Entry type instead of tuples. r=mstange https://hg.mozilla.org/integration/mozilla-inbound/rev/3b6ec4f3984e Correctly merge in the presence of reorderings. r=mstange
Attachment #8965098 - Attachment is obsolete: true
Attachment #8965097 - Flags: review+ → review?(mstange)
Attachment #8965098 - Attachment is obsolete: false
Discovering that overlay scrollbars disable partial updates made building the crash test take way longer than I would've liked.
Comment on attachment 8965097 [details] Bug 1450162. Add a crash test that invalidates our previous assumptions. https://reviewboard.mozilla.org/r/233796/#review239518 Looks great! I would be happier if you declared all the local variables with a var or a let or a const, though. ::: layout/svg/crashtests/blob-merging-and-retained-display-list.html:6 (Diff revision 3) > +<!doctype html> > +<html class="reftest-wait"> > +<script> > + var r = 40; > + var xmlns = "http://www.w3.org/2000/svg"; > + raf = requestAnimationFrame; This happens to work but it makes me a little queasy. Could you change it to const raf = f => window.requestAnimationFrame(f); ? ::: layout/svg/crashtests/blob-merging-and-retained-display-list.html:9 (Diff revision 3) > + var r = 40; > + var xmlns = "http://www.w3.org/2000/svg"; > + raf = requestAnimationFrame; > + function rect(x, y) { > + var r = document.createElementNS (xmlns, "rect"); > + r.setAttributeNS (null, "x", x); What does passing null mean, here? Does it end up doing something different then just plain setAttribute? ::: layout/svg/crashtests/blob-merging-and-retained-display-list.html:22 (Diff revision 3) > + x = rect(110, 110); > + y = rect(120, 120); > + z = rect(130, 130); > + w = rect(140, 140); > + x2 = rect(310, 140); > + y2 = rect(320, 130); > + z2 = rect(330, 120); > + w2 = rect(340, 110); maybe call these a/b/c/d? and rename the existing c to svg? ::: layout/svg/crashtests/blob-merging-and-retained-display-list.html:36 (Diff revision 3) > + c.appendChild(x); > + c.appendChild(y); > + c.appendChild(z); > + c.appendChild(w); > + raf(() => { > + // the display list partial update will end up with these items before x,y,w,z Crucial comment. Thanks. ::: layout/svg/crashtests/blob-merging-and-retained-display-list.html:60 (Diff revision 3) > + > + onload = f; > +</script> > + > +<body> > +<svg height="600" width="700" id=c> Could you switch the order of width and height? I was a bit confused for a second.
Attachment #8965097 - Flags: review+
Pushed by jmuizelaar@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f1307a26d167 Add a crash test that invalidates our previous assumptions. r=mstange
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #3) > http://www.spiegel.de/wirtschaft/soziales/hartz-iv-grosse-mehrheit-will-grundsaetzliche-aenderung-beim-arbeitslosengeld-ii-a-1201002.html I can't reproduce the crash from comment 3 anymore. :) But I found another website that still crashes: bug 1451458
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: