Closed Bug 1424280 Opened 7 years ago Closed 7 years ago

Update webrender to f9bc4a5c263e707e3498bea47d3ec9096cc3d099

Categories

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

Product:
Core
Component:
Graphics: WebRender
Version:
59 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla59
Tracking Flags:
Tracking Status
firefox59 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

(Whiteboard: [wr-mvp] [gfx-noted])

Attachments

(3 files)

Bug 1424280 - Update webrender to commit f9bc4a5c263e707e3498bea47d3ec9096cc3d099.
59 bytes, text/x-review-board-request
jrmuizel
: review+
Details
Bug 1424280 - Replace serde and serde_derive with Gankro's modified branch.
59 bytes, text/x-review-board-request
froydnj
: review+
jrmuizel
: review+
froydnj
: review+
Details
Bug 1424280 - Update cargo lockfiles and re-vendor rust dependencies.
59 bytes, text/x-review-board-request
jrmuizel
: review+
Details
+++ This bug was initially created as a clone of Bug #1423203 +++ I'm filing this as a placeholder bug for the next webrender update. I may be running a cron script [1] that does try pushes with webrender update attempts, so that we can track build/test breakages introduced by webrender on a rolling basis. This bug will hold the try push links as well as dependencies filed for those breakages, so that we have a better idea going into the update of what needs fixing. I might abort the cron job because once things get too far out of sync it's hard to fully automate fixing all the breakages. When we are ready to actually land the update, we can rename this bug and use it for the update, and then file a new bug for the next "future update". [1] https://github.com/staktrace/moz-scripts/blob/master/try-latest-webrender.sh
Whiteboard: [wr-mvp] [gfx-noted] → [wr-reserve] [gfx-noted]
WR @ e558d41b74b0f9601e75346e37a36cad553e0990 (based off autoland tip at the time of pushing) https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ecc5bab81a3c70d1394bd3a554e3b733cd907cc https://treeherder.mozilla.org/#/jobs?repo=try&revision=9e690e7b3d828cc4abbe40aac3dbfaa51f3bc134 f8 orange is pre-existing from autoland, so ignore that. Mostly still pending but no problems so far.
WR @ cb8d8d973de1e3ab2d4aed41a187faf6d65c5fd5 (also based off autoland) https://treeherder.mozilla.org/#/jobs?repo=try&revision=93e00408d00bbaf2e4f098f01d978bcc0bdf96c0 https://treeherder.mozilla.org/#/jobs?repo=try&revision=4a0c01e5c66191187936071825d1e1cbda2bc653 Linux seems green, but there's a M-e10s(gpu) which is orange. Not sure if that's intermittent or not, but I retriggered it. Windows, however, is red with a rust panic. That's no good. It's on the opt build so the backtrace is useless. Retriggered debug to see if we can get more info. Regression range: * cb8d8d97 Auto merge of #2162 - kvark:gpu-upload, r=glennw |\ | * 720c58cc GPU Cache: switch scattering OFF by default, comment the decision; Address review notes. | * 20bffb5c GPU cache: fixed the ordering of deferred updates | * d6b7800d Better error out of CacheTexture failure Proper shader includes, point size | * adfcfc5a GPU cache: wrench png saving, OSMESA fix | * c0e1b2df GPU cache: resizing ahead of time in prepare_for_updates | * d9b7ea9a GPU Cache: comments | * 361640f3 GPU Cache: refactor the old rows/cpu_blocks | * 3ee00046 GPU Cache: stress test and fixes | * 44d41236 GPU cache: target resize with content preservation | * 2f42494a GPU cache: texture/fbo binding, first working results | * 9283a4ac GPU cache: strong VBOs and multiple updates | * 2c3838ac GPU cache data upload and scatter | * d4a60dd9 Basic infrastructure for scatter style GPU cache updates * 46f9d998 Auto merge of #2198 - lsalzman:delayed-bitmaps, r=glennw |\ | * e9933462 determine whether a font has bitmaps only when fetching glyphs * 822edff1 Auto merge of #2128 - Gankro:deserialize_from, r=kvark * 36864e9b use deserialize_from for faster deserialization * 70f5e681 bump serde/serde_derive versions to prepare for soft-fork Seems likely that this will be from servo/webrender#2162, but I'll bisect to confirm.
Oh... FWIW, https://github.com/servo/webrender/issues/2162 was merged with the new code path disabled by default, so I wouldn't expect any breakage.
Both of those bisections are fine, so it's definitely from servo/webrender#2162. The debug jobs from comment 5 have a lot of panic messages with no symbols but at the end of the log file there's 6 crashdumps which all contain this stack: Thread 10 (crashed) 0 xul.dll!panic_abort::__rust_start_panic [lib.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 53 + 0x4] Found by: given as instruction pointer in context 1 xul.dll!std::panicking::rust_panic [panicking.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 608 + 0x5] 2 xul.dll!std::panicking::rust_panic_with_hook [panicking.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 593 + 0x11] 3 xul.dll!std::panicking::begin_panic<alloc::string::String> [panicking.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 538 + 0x12] 4 xul.dll!std::panicking::begin_panic_fmt [panicking.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 522 + 0x20] 5 xul.dll!std::panicking::rust_begin_panic [panicking.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 498 + 0x1c] 6 xul.dll!core::panicking::panic_fmt [panicking.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 71 + 0x27] 7 xul.dll!core::slice::slice_index_len_fail [mod.rs:05e2e1c41414e8fc73d0f267ea8dab1a3eeeaa99 : 746 + 0x10] 8 xul.dll!webrender::renderer::{{impl}}::render::{{closure}} [renderer.rs:4a0c01e5c661 : 2753 + 0x16c] 9 xul.dll!webrender::renderer::Renderer::render [renderer.rs:4a0c01e5c661 : 2681 + 0x61] 10 xul.dll!webrender_bindings::bindings::wr_renderer_render [bindings.rs:4a0c01e5c661 : 509 + 0x19] 11 xul.dll!mozilla::wr::RendererOGL::Render() [RendererOGL.cpp:4a0c01e5c661 : 149 + 0x18] 12 xul.dll!mozilla::wr::RenderThread::UpdateAndRender(mozilla::wr::WrWindowId) [RenderThread.cpp:4a0c01e5c661 : 228 + 0x5] 13 xul.dll!mozilla::wr::RenderThread::NewFrameReady(mozilla::wr::WrWindowId) [RenderThread.cpp:4a0c01e5c661 : 174 + 0xb] 14 xul.dll!mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread *,void ( mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId),1,0,mozilla::wr::WrWindowId>::Run() [nsThreadUtils.h:4a0c01e5c661 : 1192 + 0x7] 15 xul.dll!MessageLoop::RunTask(already_AddRefed<nsIRunnable>) [message_loop.cc:4a0c01e5c661 : 452 + 0xf] 16 xul.dll!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask &&) [message_loop.cc:4a0c01e5c661 : 460 + 0x31] 17 xul.dll!MessageLoop::DoWork() [message_loop.cc:4a0c01e5c661 : 535 + 0x5] 18 xul.dll!base::MessagePumpDefault::Run(base::MessagePump::Delegate *) [message_pump_default.cc:4a0c01e5c661 : 36 + 0x9] 19 xul.dll!MessageLoop::RunHandler() [message_loop.cc:4a0c01e5c661 : 319 + 0x5] 20 xul.dll!MessageLoop::Run() [message_loop.cc:4a0c01e5c661 : 299 + 0x8] 21 xul.dll!base::Thread::ThreadMain() [thread.cc:4a0c01e5c661 : 181 + 0xa] 22 xul.dll!`anonymous namespace'::ThreadFunc [platform_thread_win.cc:4a0c01e5c661 : 28 + 0x6] 23 kernel32.dll!LdrpLoadResourceFromAlternativeModule + 0x27c where renderer.rs:2753 is this line: https://hg.mozilla.org/try/file/4a0c01e5c66191187936071825d1e1cbda2bc653/gfx/webrender/src/renderer.rs#l2753
Blocks: 1424562
WR @ 2c5c04369ac8d07ee3ba708c0f45e67e09b55581 https://treeherder.mozilla.org/#/jobs?repo=try&revision=4a7fd4eedb8a41fe3a039b40ae2f887a3ae5f574 https://treeherder.mozilla.org/#/jobs?repo=try&revision=8bd956e7b8103a1bc9551c236cd36b22256b0e37 Same as before. Last night's cron job ran into a problem because serde got bumped to 1.0.24 on crates.io and we only have a replacement for 1.0.23. Trying to figure out how to convince cargo to do what we want.
That's looking good; Windows is red but that try push didn't include kvark's fix so that's expected. I'm doing another one with WR master (has all the fixes) on autoland to make sure the landing didn't have any hiccups. https://treeherder.mozilla.org/#/jobs?repo=try&revision=fcb95ac9c88147b85668c8831254c49ff6d1e168 https://treeherder.mozilla.org/#/jobs?repo=try&revision=148486f51e665753a1a9fe51d6b7c9fe730d2d3c
Alias: wr-future-update
Assignee: nobody → bugmail
Summary: Future webrender update bug → Update webrender to f9bc4a5c263e707e3498bea47d3ec9096cc3d099
Version: unspecified → 59 Branch
Comment on attachment 8936160 [details] Bug 1424280 - Update cargo lockfiles and re-vendor rust dependencies. https://reviewboard.mozilla.org/r/206916/#review212734
Attachment #8936160 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8936159 [details] Bug 1424280 - Replace serde and serde_derive with Gankro's modified branch. https://reviewboard.mozilla.org/r/206914/#review212738
Attachment #8936159 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8936158 [details] Bug 1424280 - Update webrender to commit f9bc4a5c263e707e3498bea47d3ec9096cc3d099. https://reviewboard.mozilla.org/r/206912/#review212736
Attachment #8936158 - Flags: review?(jmuizelaar) → review+
Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c9af377b8594 Update webrender to commit f9bc4a5c263e707e3498bea47d3ec9096cc3d099. r=jrmuizel https://hg.mozilla.org/integration/autoland/rev/2ee03038f5e5 Replace serde and serde_derive with Gankro's modified branch. r=jrmuizel https://hg.mozilla.org/integration/autoland/rev/8df51ada197d Update cargo lockfiles and re-vendor rust dependencies. r=jrmuizel
Try push is looking good. I landed without waiting for the r?Build these since we want the serde changes in for the all-hands, and I'm not really sure if the .cargo/config.in changes actually need build peer review or not. I'm hoping that it's a simple enough change that post-landing review is ok for it.
Priority: P2 → P1
Whiteboard: [wr-reserve] [gfx-noted] → [wr-mvp] [gfx-noted]
Comment on attachment 8936159 [details] Bug 1424280 - Replace serde and serde_derive with Gankro's modified branch. https://reviewboard.mozilla.org/r/206914/#review212970 Assuming this just replaces where we are vendoring this crate from, r+.
Attachment #8936159 - Flags: review+
Attachment #8936159 - Flags: review?(core-build-config-reviews) → review+
(In reply to Nathan Froyd [:froydnj] (Limited time-only Austin reviews; void where prohibited) from comment #22) > Assuming this just replaces where we are vendoring this crate from, r+. Yup, thanks!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: