Closed Bug 1509817 Opened 1 year ago Closed 2 months ago

Assertion failed: upload_size <= data.len() * mem::size_of::<T>() in webrender::device::gl::TextureUploader<T>::upload<T>

Categories

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

Unspecified
All
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: gsvelto, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is
report bp-ecff3ec3-067c-4097-8724-01c290181126.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4477483705794366678 mfbt/Assertions.h:311
1 xul.dll GeckoCrashOOL toolkit/xre/nsAppRunner.cpp:5350
2 xul.dll static void gkrust_shared::panic_hook toolkit/library/rust/shared/lib.rs:234
3 xul.dll static void core::ops::function::Fn::call<fn /libcore/ops/function.rs:78
4 xul.dll static void std::panicking::rust_panic_with_hook /rustc/da5f414c2c0bfe5198934493f04c676e2b23ff2e/src/libstd/panicking.rs:481
5 xul.dll static <NoType> std::panicking::begin_panic<str*> /libstd/panicking.rs:411
6 xul.dll static unsigned __int64 webrender::device::gl::TextureUploader<u8>::upload<u8> gfx/wr/webrender/src/device/gl.rs:2729
7 xul.dll static void webrender::renderer::Renderer::update_texture_cache gfx/wr/webrender/src/renderer.rs:2806
8 xul.dll static union core::result::Result<webrender::renderer::RendererStats, alloc::vec::Vec<webrender::renderer::RendererError>> webrender::renderer::Renderer::render_impl gfx/wr/webrender/src/renderer.rs:2541
9 xul.dll bool webrender_bindings::bindings::wr_renderer_render gfx/webrender_bindings/src/bindings.rs:617

=============================================================

I found two instances of this but there will be more until we fix bug 1489094 and get proper signatures.
I also found what looks like a lone instance of this on Linux with a saner signature:

https://crash-stats.mozilla.com/report/index/54f5e1bf-9d52-4aa9-ac7a-150c40181125

I'm not 100% sure it's the same crash but the stack looks close enough.
> assertion failed: upload_size <= data.len() * mem::size_of::<T>()
Blocks: wr-stability
Crash Signature: [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4477483705794366678] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.5035872941563483689] → [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4477483705794366678] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.5035872941563483689] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.16608933574218586341 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11569668431307715831 ] [@ <T>::upload ]
OS: Windows → All
Bobby, could you have caused this?
Flags: needinfo?(bobbyholley)
Priority: -- → P3
(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> Bobby, could you have caused this?

I don't think so.

There's too much inlining in the crash reports linked in comment 0, but the crash in comment 1 shows the callstack taking the ExternalImageSource::RawData branch [1] before tripping on the assertion [2]. So effectively, it appears that the data returned by the external image handler at render-time is out of sync with what ended up in the texture cache during frame building.

[1] https://searchfox.org/mozilla-central/rev/d35199ef15ffa57d190886e20d5df6471faf0870/gfx/wr/webrender/src/renderer.rs#2887
[2] https://searchfox.org/mozilla-central/rev/d35199ef15ffa57d190886e20d5df6471faf0870/gfx/wr/webrender/src/device/gl.rs#2729
Flags: needinfo?(bobbyholley) → needinfo?(aosmond)
Depends on: 1398533
I haven't changed anything in the last few days that should be related. It starts with build 20181124100112, here's the pushlog:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8264fe75578f&tochange=76c1898f6b02

nical, do you think the blob changes could be related?

https://github.com/servo/webrender/pull/3277

--

As an aside:

https://searchfox.org/mozilla-central/rev/d35199ef15ffa57d190886e20d5df6471faf0870/gfx/wr/webrender/src/device/gl.rs#2726

It seems strange that somebody might try to save a few bytes at the end by cutting off the stride on the last line? Assuming your allocator even was that granular.
Flags: needinfo?(aosmond) → needinfo?(nical.bugzilla)
Adding a few more signatures spotted in crash stats, all in [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.18014783478749618547] signature have assertion failed: upload_size <= data.len() * mem::size_of::<T>()  crash reason. Some of the crashes in [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.1803546223659788867] signature do have that crash reason as well.
Crash Signature: [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4477483705794366678] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.5035872941563483689] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.16608933574218586341 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11569668431307715831 ] [@ <T>::upload ] → [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4477483705794366678] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.5035872941563483689] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.16608933574218586341 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11569668431307715831 ] [@ ?MOZ_CrashOOL@@YAXPE…
I can reliably reproduce it using:

./mach run --temp-profile --setpref gfx.webrender.all=true https://derpibooru.org/1838330

And then clicking on the tall comic image to make the website reload it scaled to window width.

Arch Linux, GNOME, NVIDIA, screen 3840x2160, UI scale 2.
It does not trigger with devPixelsPerPx=1.0 .
The viewport size is 1280x872 CSS px.
The window size is 2560x1966.

bp-c72368ca-7681-4154-90b0-7a86d0181126
bp-c5ee9f5a-0095-4384-a3ce-a05a50181128
There's more signatures for this but they're mixed up with other unrelated stacks unfortunately.
(In reply to Jan Alexander Steffens [:heftig] from comment #7)
> I can reliably reproduce it using:
> 
> ./mach run --temp-profile --setpref gfx.webrender.all=true
> https://derpibooru.org/1838330
> 
> And then clicking on the tall comic image to make the website reload it
> scaled to window width.

Thanks! Quick repro with additional logging:

texformat BGRA8 rect.size 512×-105 stride Some(8000) upload_size: 18446744073708705664 data.len() 98296000 sizeof 1

So umm negative widths are bad?
I think the code at https://searchfox.org/mozilla-central/rev/3fdc51e66c9487b39220ad58dcee275fca070ccd/gfx/wr/webrender/src/texture_cache.rs#1450 doesn't account for the case where dirty.origin.y > size.height for example.

Texture cache update id CacheTextureId(1) from origin (0,0) size 464×512 dirty TypedRect(2000×148 at (-1536,1393)) -> TypedRect(2000×-881 at (-1536,1393))
Dzmitry, looks like you added this code back in servo/webrender#2829 - the semantics of `origin`, `size` and `dirty` are not obvious to me. There is a comment saying that the dirty rect has to intersect the area (which I assume is defined by `origin` and `size` but if the two rects are relative to the same coordinate space the computation doesn't make sense to me. Can you take a look?

(STR for crash in comment 7 if you need them)
Flags: needinfo?(nical.bugzilla) → needinfo?(dmalyshau)
Duplicate of this bug: 1512405
Crash Signature: ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.1803546223659788867] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.18014783478749618547] [@ <T>::upload ] → ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.1803546223659788867] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.18014783478749618547] [@ <T>::upload ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.12926764209168481736 ] [@ ?MOZ_CrashOOL@@YAXPBDH0@Z.llvm.2283102163905723673 ] [@ ?MOZ_…
I'll take a look.
Flags: needinfo?(dmalyshau) → needinfo?(aosmond)
Crash Signature: ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.12171157871972783571 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4342330752790445268 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.10214329888179869908 ] → ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.12171157871972783571 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4342330752790445268 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.10214329888179869908 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11508361402999640865 ]
Crash Signature: ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.12171157871972783571 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4342330752790445268 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.10214329888179869908 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11508361402999640865 ] → ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.12171157871972783571 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4342330752790445268 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.10214329888179869908 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11508361402999640865 ] [@ ?MOZ_CrashOOL@@YAXP…
Duplicate of this bug: 1523586
Crash Signature: ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.2770432487422430110 ] → ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.2770432487422430110 ] [@ webrender::device::gl::TextureUploader<T>::upload<T> ]
Summary: Crash in ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.4477483705794366678 → Assertion failed: upload_size <= data.len() * mem::size_of::<T>() in webrender::device::gl::TextureUploader<T>::upload<T>

This seems to have gone away / morphed. The specific panic changed:

https://searchfox.org/mozilla-central/rev/d24696b5abaf9fb75f7985952eab50d5f4ed52ac/gfx/wr/webrender/src/device/gl.rs#3565

But I don't see it in the crash reports anymore for any recent builds. I'd say file a new bug against the new panic if it comes up.

Status: NEW → RESOLVED
Closed: 2 months ago
Flags: needinfo?(aosmond)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.