https://crash-stats.mozilla.com/signature/?product=Firefox&signature=webrender%3A%3Arender_task%3A%3ARenderTask%3A%3Anew_picture This one seems to have started Sunday 23rd (we did a wr update that day to revert another crash).

bp-eb8392d0-8f62-4f50-b241-bec670180925 Win10 > |[G0][GFX1-]: Attempting to create a render task of size 11282560x11282654 (t=63907.5) bp-0f7b6bd6-a751-4e8a-9336-21d9d0180924 Linux > |[0][GFX1-]: Attempting to create a render task of size 19502x3088 (t=7290.53) bp-4ce03933-222d-4749-af2e-0390e0180923 Win10 > |[G0][GFX1-]: Attempting to create a render task of size 16563x47812 (t=700.331)

I think that this is coming from a reasonably large picture with an unreasonably large blur radius applied to it, causing us to attempt to create a very big render task. We should probably at least set some kind of maximum size on blur radii. I can easily reproduce the crash by creating a test yaml file with a 100000px blur radius.

Do we know why this would have regressed?

This may be related to bug 1490007, specifically the analysis in bug 1490007 comment 3 and onward. I got sidetracked with memory stuff, and haven't gotten back to it.

https://addons.mozilla.org/firefox/addon/bugzilla-crash-stop/ Changes between 20180922220057 (no crashes) and 20180923100316 (6 crashes / 3 installs) according to mozregression: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=221c18ebe962f68358b4cba927df9099ea935b40&tochange=5c2a8331f82c11037b458f2733ae9813fa16f906

So likely the WR update (https://github.com/servo/webrender/compare/97a3807ea8266c324feb3ecada2ac5fd78c80e9b...3f6016fbb6fb93b2f1fc7046bce186555ca836f3).

Glenn -- it's late for Nical. Can I ask you to take this bug and find the most practical solution to get the crash rate down quickly? This one is on relman's radar. Nical -- If there is any info you have that can help Glenn resolve this faster, please dump it here. Thanks.

So Markus told me we clamp the blur radius to 100px in the software backend. The fastest fix would be to do the same when building the display list (can land without a wr update). I don't have a computer with the guts to compiler gecko at home so I'm leaving that up to Glenn if need be). Clamping in webrender would make sense (although needs a WR update to get the crashes down). I'd do it either while building the scene or in picture.rs when creating the render task.

Yes, I can look into this today. I'm not sure that it's as simple as suggested though. We already clamp the blur radius to 300px inside WR, so it's probably something a bit more involved than that.

Ah, I was mistaken - we only apply the blur radius clamping in the box shadow code. We should be able to apply this as a general clamp to blur filters too. So fixing this should indeed be trivial.

https://github.com/servo/webrender/pull/3120 contains a fix for the synthetic test case in comment 2. Hopefully this also fixes the real pages that this has been occurring on.

The WR fixes for this have landed now, so this will hopefully be fixed by the next WR update.

Still happening.

Hi Nical, It's a holiday weekend for Glenn. Can I ask you to take a look at why this is still happening?

I found a similar issue with text shadow, I'll put a PR up quickly.

will crash on https://www.qualcomm.com/company/careers/locations/san-diego .If it doesnt repro automatically, try selecting some text on page, or hover mouse over the drop-down menus on top

Upcoming WR update wouldn't fix the drop down menus. RUST_BACKTRACE=1 mozregression --repo mozilla-inbound --launch ab5269bd3c21 -B debug --pref gfx.webrender.all:true -a https://www.qualcomm.com/company/careers/locations/san-diego > 2:07.69 INFO: [GFX1-]: Attempting to create a render task of size 202x25729 > 2:07.69 INFO: ERROR 2018-09-29T22:45:07Z: webrender::render_task: Attempting to create a render task of size 202x25729 > 2:07.69 INFO: thread 'WRRenderBackend#1' panicked at 'explicit panic', gfx/webrender/src/render_task.rs:44:9

Thanks a lot for the test case. I had a look and there appear to be some interaction with a scaling transformation that causes us to not do a great job a clipping the primitive rect here https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/gfx/webrender/src/picture.rs#461 which is then used as the size of the render target here: https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/gfx/webrender/src/picture.rs#736 pic_rect: x: -21, y: -10795.6494, width: 202, height: 146065.906, clipped: x: -21, y: -10796, width: 202, height: 146067, prim_metadata.clipped_world_rect: x: 382.799988, y: 114.209717, width: 202, height: 284, map_pic_to_raster: kind: Local, bounds: x: -403.799988, y: -69535.6016, width: 1280, height: 534889.25, map_raster_to_wrold: kind ScaleOffset( x: 1, y: 0.00194432773, x: 403.799988, y: 135.199997) bounds: x:0, y: 0, width: 1280, height: 1040, I only superficially understand this code so I'll defer to Glenn.

Thanks for the repro, I can make this occur locally by hovering over the dropdown menus on that page. I'll investigate today.

This patch contains a temporary workaround, until I implement the proper fix for this (described in the patch commit notes). https://github.com/servo/webrender/pull/3149. I'll work on the proper fix today.

The WR patch for this has landed. Once the next WR update lands, we should be able to verify this and close it as FIXED. Although the fix in WR is a workaround, it's a genuine fix that won't affect performance / correctness. The follow up work is just needed to re-enable this feature for picture caching support.

Hi, I found this bug report through about:support, everytime I try to scroll down on https://www.magicleap.com/magic-leap-one Nightly crashes on me. https://crash-stats.mozilla.com/report/index/f68a21e9-994c-442c-b6b7-16fd00181210 is one of them.