Closed Bug 1679477 Opened 3 years ago Closed 3 years ago

Assertion `l0.y == r0.y' failed.

Categories

(Core :: Graphics: WebRender, defect)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
85 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- unaffected
firefox84 --- unaffected
firefox85 --- fixed

People

(Reporter: geeknik, Assigned: lsalzman)

Details

(4 keywords, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(4 files)

Attached file 1434.html

Similar in style to Bug 1678938. Clean profile with Nightly Build ID 20201126212448 is all that is needed with the attached reproducer.

firefox: src/gl.cc:3569: void draw_perspective_spans(int, Point3D *, glsl::Interpolants *, Texture &, int, Texture &, const ClipRect &) [P = unsigned int]: Assertion `l0.y == r0.y' failed.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=46.6874) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Exiting due to channel error.

No ASAN stacktrace was generated.

Flags: sec-bounty?
Group: firefox-core-security → core-security
Type: task → defect
Component: Security → Canvas: WebGL
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64
Version: unspecified → Trunk
Group: core-security → gfx-core-security

This was found by fuzzers @ Fri, 27 Nov 2020 16:44:57 +0000. Waiting on reduced test case.

User Story: (updated)
User Story: (updated)
Attached file testcase.html
Attached file prefs.js
Flags: in-testsuite?
Keywords: crash, testcase
#0 0x7f195adb5f47 in gsignal /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51
#1 0x7f195adb78b0 in abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:79
#2 0x7f195ada7429 in __assert_fail_base /build/glibc-2ORdQG/glibc-2.27/assert/assert.c:92
#3 0x7f195ada74a1 in __assert_fail /build/glibc-2ORdQG/glibc-2.27/assert/assert.c:101
#4 0x7f19474836bf in draw_perspective_spans<unsigned int> src/gfx/wr/swgl/src/gl.cc:3569:3
#5 0x7f19474836bf in draw_perspective_clipped(int, glsl::vec4_scalar*, glsl::vec3*, Texture&, int, Texture&) src/gfx/wr/swgl/src/gl.cc:3759:5
#6 0x7f194734330b in draw_perspective src/gfx/wr/swgl/src/gl.cc
#7 0x7f194734330b in draw_quad(int, Texture&, int, Texture&) src/gfx/wr/swgl/src/gl.cc:3865:5
#8 0x7f194734196a in draw_elements<unsigned short> src/gfx/wr/swgl/src/gl.cc:3974:5
#9 0x7f194734196a in DrawElementsInstanced src/gfx/wr/swgl/src/gl.cc:4044:7
#10 0x7f1946f71d87 in _$LT$gleam..gl..ErrorReactingGl$LT$F$GT$$u20$as$u20$gleam..gl..Gl$GT$::draw_elements_instanced::h7af1af1250559027 src/third_party/rust/gleam/src/gl.rs:98:26
#11 0x7f1947143aea in webrender::device::gl::Device::draw_indexed_triangles_instanced_u16::h691079694d5df086 src/gfx/wr/webrender/src/device/gl.rs:3407:9
#12 0x7f1947143aea in webrender::renderer::Renderer::draw_instanced_batch::hc3cc3eae15908cbf src/gfx/wr/webrender/src/renderer.rs:4328:13
#13 0x7f19471474e9 in webrender::renderer::Renderer::draw_alpha_batch_container::h54d2ec50ef463820 src/gfx/wr/webrender/src/renderer.rs:4780:17
#14 0x7f19471551dc in webrender::renderer::Renderer::draw_color_target::hbdac3bb58b8f1e2a src/gfx/wr/webrender/src/renderer.rs:5433:13
#15 0x7f19471551dc in webrender::renderer::Renderer::draw_frame::hc1c13f2343c96251 src/gfx/wr/webrender/src/renderer.rs:6430:17
#16 0x7f194712fc33 in webrender::renderer::Renderer::render_impl::he83997d099c56357 src/gfx/wr/webrender/src/renderer.rs:3663:17
#17 0x7f194712cf0a in webrender::renderer::Renderer::render::he364f654a8330632 src/gfx/wr/webrender/src/renderer.rs:3414:30
#18 0x7f1946e8530c in wr_renderer_render src/gfx/webrender_bindings/src/bindings.rs:614:11
#19 0x7f1940fa0b6e in mozilla::wr::RendererOGL::UpdateAndRender(mozilla::Maybe<mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> > const&, mozilla::Maybe<mozilla::wr::ImageFormat> const&, mozilla::Maybe<mozilla::Range<unsigned char> > const&, bool*, mozilla::wr::RendererStats*) src/gfx/webrender_bindings/RendererOGL.cpp:193:8
#20 0x7f1940f9f944 in mozilla::wr::RenderThread::UpdateAndRender(mozilla::wr::WrWindowId, mozilla::layers::BaseTransactionId<mozilla::VsyncIdType> const&, mozilla::TimeStamp const&, bool, mozilla::Maybe<mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> > const&, mozilla::Maybe<mozilla::wr::ImageFormat> const&, mozilla::Maybe<mozilla::Range<unsigned char> > const&, bool*) src/gfx/webrender_bindings/RenderThread.cpp:488:31
#21 0x7f1940f9f3bf in mozilla::wr::RenderThread::HandleFrameOneDoc(mozilla::wr::WrWindowId, bool) src/gfx/webrender_bindings/RenderThread.cpp:325:3
#22 0x7f1940fa84de in applyImpl<mozilla::wr::RenderThread, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), StoreCopyPassByConstLRef<mozilla::wr::WrWindowId>, StoreCopyPassByConstLRef<bool> , 0, 1> /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1096:12
#23 0x7f1940fa84de in apply<mozilla::wr::RenderThread, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool)> /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1102:12
#24 0x7f1940fa84de in mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1148:13
#25 0x7f193ff46acf in MessageLoop::RunTask(already_AddRefed<nsIRunnable>) src/ipc/chromium/src/base/message_loop.cc:465:9
#26 0x7f193ff47615 in MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask&&) src/ipc/chromium/src/base/message_loop.cc:473:5
#27 0x7f193ff478ba in MessageLoop::DoWork() src/ipc/chromium/src/base/message_loop.cc:548:13
#28 0x7f193ff482a0 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) src/ipc/chromium/src/base/message_pump_default.cc:35:31
#29 0x7f193ff46793 in MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:334:10
#30 0x7f193ff466ad in RunHandler src/ipc/chromium/src/base/message_loop.cc:327:3
#31 0x7f193ff466ad in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:309:3
#32 0x7f193ff54937 in base::Thread::ThreadMain() src/ipc/chromium/src/base/thread.cc:191:16
#33 0x7f193ff4fea9 in ThreadFunc(void*) src/ipc/chromium/src/base/platform_thread_posix.cc:40:13
#34 0x7f195beba6da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
#35 0x7f195ae98a3e in clone /build/glibc-2ORdQG/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Is this just a numeric comparison failure that will lead to bad drawing, or something index-y that's a potential memory corruption issue?

Flags: needinfo?(jgilbert)

I feel like both of these WebRender SWGL bugs should be in WebRender, so I'll move it there. Feel free to move it back if appropriate.

Component: Canvas: WebGL → Graphics: WebRender

SWGL is lsalzman

Flags: needinfo?(jgilbert) → needinfo?(lsalzman)
Blocks: gfx-triage

Two issues:

Addressing Daniel Veditz, this only affects rasterization, potentially making it draw an incorrect results, but does not result in memory corruption in this instance. It's just a diagnostic debug-only assert. Also, Software WebRender is hidden behind a pref currently except for a small Nightly-only experiment population strictly limited to a subset of Linux users.

Secondly, to Tyson Smith, this fails to reproduce at all when I pref SW-WR on. So this would seem to indicate this requires some further prefs or circumstances to trigger that are definitely non-standard?

Flags: needinfo?(lsalzman) → needinfo?(twsmith)

The prefs file that was in use when the fuzzers found this is attached.

Flags: needinfo?(twsmith)

(In reply to Tyson Smith [:tsmith] from comment #10)

The prefs file that was in use when the fuzzers found this is attached.

Is it possible to get a list of prefs that are non-standard instead of just the whole pref dump? It's hard to see what is special that has changed in the sea of prefs.

Flags: needinfo?(twsmith)

Unfortunately we don't have a way to reduce prefs.js files yet. The file is annotated with variations from the normal prefs used to fuzzed. There is also a Pernosco session available (see comment 5). The only other thing I can think of that might influence this is the use of Xvfb.

These are the changes from the base fuzzing prefs.js file.

// 'gfx.webrender.all' defined by variant 'webrender'
user_pref("gfx.webrender.all", true);
// 'gfx.webrender.software' defined by variant 'webrender'
user_pref("gfx.webrender.software", true);
...
// 'layout.css.backdrop-filter.enabled' defined by variant 'webrender'
user_pref("layout.css.backdrop-filter.enabled", true);
Flags: needinfo?(twsmith)

(In reply to Tyson Smith [:tsmith] from comment #12)

Unfortunately we don't have a way to reduce prefs.js files yet. The file is annotated with variations from the normal prefs used to fuzzed. There is also a Pernosco session available (see comment 5). The only other thing I can think of that might influence this is the use of Xvfb.

These are the changes from the base fuzzing prefs.js file.

// 'gfx.webrender.all' defined by variant 'webrender'
user_pref("gfx.webrender.all", true);
// 'gfx.webrender.software' defined by variant 'webrender'
user_pref("gfx.webrender.software", true);
...
// 'layout.css.backdrop-filter.enabled' defined by variant 'webrender'
user_pref("layout.css.backdrop-filter.enabled", true);

The layout.css.backdrop-filter.enabled pref did not alter the results for me either. It still fails to reproduce.

I verified locally I can reproduce the issue using Grizzly. I used m-c 20201207-7167ab3f6e8d.

I ran python3 -m grizzly.replay <firefox-debug-build> testcase.html -p prefs.js --xvfb.

I also confirmed that the only prefs that is needed to trigger the issue is gfx.webrender.software=true and Xvfb is required for the attached test case.

I also noticed the Pernosco session was not loading properly and email support. They have replied and said it will be functional shortly.

It appears this bug can only be reproduced currently in debug builds. Even release nightly builds are not exposed.

Assignee: nobody → lsalzman
Status: NEW → ASSIGNED

I did not have gfx.webrender.software=true set in our ASan Nightly profile. In fact, no preferences were changed beyond setting an email address for the ASan reporter.

(In reply to Brian Carpenter [:geeknik] from comment #17)

I did not have gfx.webrender.software=true set in our ASan Nightly profile. In fact, no preferences were changed beyond setting an email address for the ASan reporter.

You were in the subset of Linux Nightly users who just recently got software webrender enabled by default as an experiment.

(In reply to Lee Salzman [:lsalzman] from comment #18)

You were in the subset of Linux Nightly users who just recently got software webrender enabled by default as an experiment.

So just to make sure I understand correctly, that experiment will override prefs.js? Because I just made sure that gfx.webrender.software was set to false and this assert still happens. I also don't see anything about software webrender listed under about:preferences#experimental.

Addressing Daniel Veditz, this only affects rasterization, potentially making it draw an incorrect results, but does not result in memory corruption

Thanks!

Group: gfx-core-security
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/515d55365c2b
avoid division by zero W coordinate. r=jimb
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch
No longer blocks: gfx-triage
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: