1677221 - assertion failed: mem::size_of::<T>() <= slice.len()

Status: RESOLVED DUPLICATE of bug 1812136

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

Description

[Timothy Nikkel (:tnikkel)]

https://crash-stats.mozilla.org/report/index/feefa1e3-4fc8-4059-a67b-30c9c0201113

I hit this when dragging a wealthsimple.com tab from a browser window on retina screen on my macbook pro to a window on an external screen that was not retina, while playing the platform meeting in the tab that was newly exposed on the retina screen.

I can not reproduce.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

The stack doesn't make any sense. The url reported in the crash is: https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg

Comment 2

[Timothy Nikkel (:tnikkel)]

Yeah, the stack isn't great.

I did have https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg open in a background tab, but I hadn't switched to it in a while and I don't think it was anywhere near the location on the tabbar where I dropped the tab.

Comment 3

[Timothy Nikkel (:tnikkel)]

And this is on beta.

Comment 4

[Darkspirit]

https://searchfox.org/mozilla-central/rev/44e6dfd7e02edd95e5fd4d4c25c8b946131f92cd/gfx/webrender_bindings/src/moz2d_renderer.rs#86

https://crash-stats.mozilla.org/search/?moz_crash_reason=~assertion%20failed%3A%20mem%3A%3Asize_of%3A%3A%3CT%3E%28%29%20%3C%3D%20slice.len%28%29&product=Firefox&date=%3E%3D2020-10-13T23%3A14%3A00.000Z&date=%3C2020-11-13T23%3A14%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Comment 5

[Darkspirit]

I know nothing, but I remember "Disable RecycleAllocator for RDD process" when using OpenGL on Mac and ask myself whether MacIOSurface is used for blob images as well, if it could have influenced things or if a pref has been manually enabled.
6 months ago, bug 1619882 comment 74 mentioned IOSurface UAF. That Linux DMABUF bug only occured under system load and flickering/out of order frames were described as UAF scenario.
bug 1665411 was filed one month after bug 1653409 merged.

---

https://crash-stats.mozilla.org/search/?moz_crash_reason=~assertion%20failed%3A%20mem%3A%3Asize_of%3A%3A%3CT%3E%28%29%20%3C%3D%20slice.len%28%29&address=%3D0x0&build_id=%3E20200501000000&product=Firefox&date=%3E%3D2020-08-14T02%3A37%3A00.000Z&date=%3C2020-11-14T02%3A37%3A00.000Z&_facets=signature&_sort=version&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports

If we focus on 0x0 crashes after 2020-05-01, build 20200818092452 is the first affected one after three months.
mozregression --good 2020-08-15 --bad 20200818092452

0:04.63 INFO: Last good revision: ffc01c0f13a841719e86d032ac27fe9dbc1fc5f7 (2020-08-15)
0:04.63 INFO: First bad revision: 483ef87aa6e85cb340d1c17b5b87bb7c217fb3b8 (2020-08-18 09:24:52)
0:04.63 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ffc01c0f13a841719e86d032ac27fe9dbc1fc5f7&tochange=483ef87aa6e85cb340d1c17b5b87bb7c217fb3b8

These looked related to blob images:
SVG:

00fac1d4990f17a92ae47796c05c76710d136272 Boris Chiou — Bug 1639963 - Support aspect-ratio for svg frames. r=emilio
802185dc6fff8db8bc07026deb29f3657d6f2cd7 Boris Chiou — Bug 1639963 - Support aspect-ratio for svg object and iframe (i.e. nsSubDocumentFrame). r=emilio

Mac:

ae4adc3f423ccbb375e425891c09f5ace4629cf8 Lee Salzman — Bug 1657440 - avoid letting Skia query style information for Mac fonts. r=jfkthame

Texture cache:

8a1b47a902ab9997b4af0ee08d998fb494c08f6b Glenn Watson — Bug 1658182 - Fix texture cache items not being evicted. r=kvark
5b2ffcf4d6d831c662685f17cda7e335d5f60dcf Glenn Watson — Bug 1623792 - Pt 9 - Refactor how exceeding max cache slices works. r=kvark

Added "return nullptr":

9de80fbdf625b3a7d514328607bc212046957170 Miko Mynttinen — Bug 1627616 - Avoid wrapping SourceSurfaceOffset around uninitialized SourceSurface r=bas

Comment 6

[Clouseau (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/002a873f-75b8-4ed1-878e-495c80261019

Reports with a different stack in the same spike: https://crash-stats.mozilla.org/report/index/056c1165-2b67-4eb6-bfd2-8689b0261020, https://crash-stats.mozilla.org/report/index/3d84a218-3fd3-447a-93ee-b81a70261020

MOZ_CRASH Reason:

assertion failed: mem::size_of::<T>() <= slice.len()

Top 10 frames:

0  libxul.so  RustMozCrash  mozglue/static/rust/wrappers.cpp:17
1  libxul.so  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:99
2  libxul.so  <mozglue_static::panic_hook as core::ops::function::FnOnce<(&std::panic::PanicHo...
3  libxul.so  std::panicking::panic_with_hook  library/std/src/panicking.rs:833
4  libxul.so  std::panicking::panic_handler::{closure#0}  library/std/src/panicking.rs:691
5  libxul.so  std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler:...  library/std/src/sys/backtrace.rs:182
6  libxul.so  __rustc::rust_begin_unwind  library/std/src/panicking.rs:689
7  libxul.so  core::panicking::panic_fmt  library/core/src/panicking.rs:80
8  libxul.so  core::panicking::panic  library/core/src/panicking.rs:150
9  libxul.so  webrender_bindings::moz2d_renderer::BlobReader::read_entry  gfx/webrender_bindings/src/moz2d_renderer.rs

Filed because this signature's crash volume spiked. 518 reports from 249 distinct installations on the release build of 2026-10-07 (buildid 20261007201254); the preceding 1 build-day had 11 report, and the loudest of its 5 earlier builds in the 42 days before had 23. That is 22.5x the loudest of the preceding build-days and of this signature's builds over the 42 days before (Clouseau's bar is 3x, and the Poisson excess of the day against that baseline is z = 35.87, bar 3.62). This signature is not new: its first report is in build 20180923100316 (2018-09-23), 2936 days before this build.

Clouseau analysis (automated -- nothing below was checked by a human; a claim it could not ground is deliberately absent):

The GPU process panics on the Compositor thread with assertion failed: mem::size_of::<T>() <= slice.len(). This happens when merge_blob_images (called from Moz2dBlobImageHandler::update) looks in the cached blob for an unchanged item's bounds, and CachedReader::next_entry_with_bounds reads past the end of the old blob's index because no entry has those bounds. In other words, Gecko sent a partial blob update whose items outside the dirty rect don't match the cached blob. This is an old crash. The new part is a big jump on Fenix 158.0 release only, across many Android versions and GPUs, while 157.0.1 and 159 beta/nightly stayed flat. A plausible exposing change is 11de34f03090 (bug 2070998), which changes which SVG items are grouped into blob images. However, most of the rise begins on 2026-10-14, well after 158.0 shipped, so a trigger tied to that date has not been ruled out. Next steps: test the grouping change (for example, compare crash rates with the grouping prefs added in bug 2070998 set to restore the old behaviour), check whether any Nimbus or remote pref change landed around 2026-10-13, and add a diagnostic or a soft-fail (invalidate the whole blob) in place of the panic in next_entry_with_bounds.

Starting point -- a candidate, NOT an established cause (low confidence): 11de34f03090 (bug 2070998) by :nical.

Possibly exposed by this change, not created by it: the signature dates from 2018. The diff changes AssessBounds to compare item size in device pixels instead of app units, and replaces the inverted isLast = it.HasNext() with next == aList->end() in Grouper::ConstructGroups. Both change which SVG display items are recorded inside DIGroup blob images, so more updates take the partial-merge path that panics when an invalidation is lost (the latent defect tracked in bugs 1805333 and 1812136). Supporting this, 158.0's crash share was already about 3 per 1000 in its first days against 0.11 for 157.0.1, though from small counts. Against it, the main rise starts on 2026-10-14 inside 158.0's life, which this change alone does not explain. No path from the diff to mismatched bounds has been traced.

Possible path to the crash:

Mechanism (observed): convert_from_bytes runs assert!(mem::size_of::<T>() <= slice.len()). The assert fails when BlobReader::read_entry is called with the old blob's index already used up, and the Rust panic hook turns it into a SIGSEGV-style crash report.

Path (observed from source and stack):

1. WebRenderBridgeParent::RecvSetDisplayList (or an APZ-triggered HandleWrTransactionEvents) sends a transaction containing a blob image update to ApiResources::update_blob_image.
2. Moz2dBlobImageHandler::update calls merge_blob_images(old, new, dirty_rect, ...).
3. For each new entry whose preserved bounds are not inside the dirty rect, it calls old_reader.next_entry_with_bounds(&new.bounds, &dirty_rect).
4. next_entry_with_bounds loops on self.reader.read_entry() with no end-of-index check, relying on the comment's assumption that a matching entry always exists, so a missing match runs off the end and panics.

Precondition (inferred, medium): the content process sent a partial blob that contains an unchanged item whose bounds are absent from the cached blob, meaning an invalidation or bounds change never reached WebRender. This matches the analysis in bugs 1805333 and 1812136, which this run did not re-verify.

Trigger (unknown): the jump is confined to 158.0 and grows from 2026-10-14 across many devices and Android versions. That points either to a content or deployment change on that date interacting with 158's grouping changes, or to something not visible in crash data.

Checked:

• convert_from_bytes asserts mem::size_of::<T>() <= slice.len(), which is exactly the MOZ_CRASH_REASON text. (gfx/webrender_bindings/src/moz2d_renderer.rs@eb9a6e3a7368:97-100)
• next_entry_with_bounds loops on read_entry() with no end check; its own comment says it panics if the bounds are not found. (gfx/webrender_bindings/src/moz2d_renderer.rs@eb9a6e3a7368:355-375)
• merge_blob_images calls next_entry_with_bounds for every new entry whose preserved bounds are not inside the dirty rect; update calls merge_blob_images at line 679, matching stack frame #10. (gfx/webrender_bindings/src/moz2d_renderer.rs@eb9a6e3a7368:437-446,679)
• The three sampled clusters all crash on the Compositor thread of the GPU process with the same reason, coming in through either RecvSetDisplayList or an APZ runnable via HandleWrTransactionEvents. (brief stacks 1-3 (002a873f, 056c1165, 3d84a218))
• Over the last 10 days on all channels, the rise is almost entirely 158.0 (for example 10-19: 145 of 149). 157.0.1, 159 beta and 160 nightly stay in single digits. (facets version by_day all_channels, 10d)
• From 2026-10-14 the rise spans Android 28, 31, 33, 35, 36 and 37 rather than one OS version. (facets platform_version by_day release, 21d)
• 158.0's share was about 3 per 1000 in its first days, against 0.11 for 157.0.1, and rose to about 10 per 1000 from 2026-10-14. (brief crash-rate-by-version table)
• 11de34f03090 changes the AssessBounds size calculation to device pixels and fixes the inverted isLast in Grouper::ConstructGroups, so SVG item grouping into blobs changes. (mcp__patch__diff 11de34f03090 gfx/layers/wr/WebRenderCommandBuilder.cpp)

Alternatives considered:

• Hardware fault or bit flips: disfavored -- 0% bit-flip annotations, many CPU models and GPU vendors (Adreno, Xclipse/ANGLE, Mali), and a deterministic assertion.
• Single device, driver or OS version: disfavored -- the spike days span Android 28 to 37 and several GPU families.
• 5709a300bdb7 on its own: disfavored -- with default pref values its runtime changes are a debug-only highlight and profiler-only stats; grouping behaviour is unchanged unless the prefs are set.
• Rollout volume alone: disfavored -- the rate is normalised per 1000 crash reports of the same version, and it still triples inside 158.0 from 2026-10-14.
• 3b6ec4f3984e (bug 1450162), named by one pipeline run as the origin of the line: unresolved -- blame origin of the merge code at most, not a cause of this rate change; diff not read.

Worth checking first:

• What changed on about 2026-10-13/14 for 158.0 users: check Nimbus and remote-settings pref deployments for Fenix 158 (especially any gfx.webrender.* pref) and whether a popular site started serving heavy SVG content; crash URL data (protected) could reveal a dominant site.
• Whether 11de34f03090 raises the rate: compare 158.0 crash rate with the grouping behaviour restored, or check whether 158 beta builds before and after the change differ (beta volume is small).
• Which Gecko path loses the invalidation (bug 1805333 / 1812136, e.g. DIGroup::EndGroup exiting early on an empty visible rect): add a diagnostic in next_entry_with_bounds that records the missing bounds, dirty rect and visible rects, or replace the panic with a fallback that re-requests a full blob update.

:nical, can you have a look please?

Posted automatically by Clouseau, which analyses release crashes with an LLM. Nothing above was written or checked by a human.

Comment 7

[Nicolas Silva [:nical]]

This looks like bug 1812136

Comment 8

[BugBot [:suhaib / :marco]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on release

:gw, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 9

[Glenn Watson [:gw]]

Will likely be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1812136