Closed Bug 1509817 Opened 4 years ago Closed 3 years ago

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


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






(Reporter: gsvelto, Unassigned)


(Blocks 1 open bug)


(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/
3 xul.dll static void core::ops::function::Fn::call<fn /libcore/ops/
4 xul.dll static void std::panicking::rust_panic_with_hook /rustc/da5f414c2c0bfe5198934493f04c676e2b23ff2e/src/libstd/
5 xul.dll static <NoType> std::panicking::begin_panic<str*> /libstd/
6 xul.dll static unsigned __int64 webrender::device::gl::TextureUploader<u8>::upload<u8> gfx/wr/webrender/src/device/
7 xul.dll static void webrender::renderer::Renderer::update_texture_cache gfx/wr/webrender/src/
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/
9 xul.dll bool webrender_bindings::bindings::wr_renderer_render gfx/webrender_bindings/src/


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:

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.

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:

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


As an aside:

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

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.

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
> 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 mean negative heights)
I think the code at 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:

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.

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