Assertion `l0.y == r0.y' failed.
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
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)
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.
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 1•3 years ago
|
||
This was found by fuzzers @ Fri, 27 Nov 2020 16:44:57 +0000. Waiting on reduced test case.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Comment 3•3 years ago
|
||
Updated•3 years ago
|
Comment 4•3 years ago
|
||
#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
Comment 5•3 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/hZ0MvheFwqHBariAH8bJzw/index.html
Comment 6•3 years ago
|
||
Is this just a numeric comparison failure that will lead to bad drawing, or something index-y that's a potential memory corruption issue?
Comment 7•3 years ago
|
||
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.
Updated•3 years ago
|
Assignee | ||
Comment 9•3 years ago
•
|
||
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?
Comment 10•3 years ago
|
||
The prefs file that was in use when the fuzzers found this is attached.
Assignee | ||
Comment 11•3 years ago
|
||
(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.
Comment 12•3 years ago
•
|
||
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);
Assignee | ||
Comment 13•3 years ago
|
||
(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.
Comment 14•3 years ago
•
|
||
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.
Assignee | ||
Comment 15•3 years ago
|
||
It appears this bug can only be reproduced currently in debug builds. Even release nightly builds are not exposed.
Assignee | ||
Comment 16•3 years ago
|
||
Updated•3 years ago
|
Reporter | ||
Comment 17•3 years ago
|
||
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.
Assignee | ||
Comment 18•3 years ago
|
||
(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.
Reporter | ||
Comment 19•3 years ago
•
|
||
(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
.
Assignee | ||
Comment 20•3 years ago
|
||
See bug 1677293
Updated•3 years ago
|
Comment 21•3 years ago
|
||
Addressing Daniel Veditz, this only affects rasterization, potentially making it draw an incorrect results, but does not result in memory corruption
Thanks!
Comment 22•3 years ago
|
||
Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/515d55365c2b avoid division by zero W coordinate. r=jimb
Comment 23•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Description
•