Crash in [@ <webrender::compositor::sw_compositor::SwCompositor as webrender::composite::Compositor>::bind] in distro build because of missing sse2
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox89 | --- | unaffected |
firefox90 | --- | wontfix |
firefox91 | --- | fixed |
firefox92 | --- | fixed |
People
(Reporter: wsmwk, Assigned: lsalzman, NeedInfo)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression, topcrash)
Crash Data
Attachments
(2 files)
(deleted),
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details |
(deleted),
text/x-phabricator-request
|
Details |
Linux and Mac. new in Firefox 90.0b12. regression?
Crash report: https://crash-stats.mozilla.org/report/index/59b59287-646f-4af6-922d-962330210705
MOZ_CRASH Reason: ```assertion failed: (left == right)
left: `Rect(0x0 at (0, 0))`,
right: `Rect(0x0 at (0, 427))````
Top 10 frames of crashing thread:
0 libxul.so RustMozCrash /build/firefox-IXYFrX/firefox-90.0~b12+build1/mozglue/static/rust/wrappers.cpp:17
1 libxul.so mozglue_static::panic_hook /build/firefox-IXYFrX/firefox-90.0~b12+build1/mozglue/static/rust/lib.rs:89
2 libxul.so core::ops::function::Fn::call /build/rustc-bpWQIb/rustc-1.47.0+dfsg1+llvm/library/core/src/ops/function.rs:70
3 libxul.so std::panicking::rust_panic_with_hook /build/rustc-bpWQIb/rustc-1.47.0+dfsg1+llvm/library/std/src/panicking.rs:573
4 libxul.so std::panicking::begin_panic_handler::{{closure}} /build/rustc-bpWQIb/rustc-1.47.0+dfsg1+llvm/library/std/src/panicking.rs:476
5 libxul.so std::sys_common::backtrace::__rust_end_short_backtrace /build/rustc-bpWQIb/rustc-1.47.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:153
6 libxul.so rust_begin_unwind /build/rustc-bpWQIb/rustc-1.47.0+dfsg1+llvm/library/std/src/panicking.rs:475
7 libxul.so std::panicking::begin_panic_fmt /build/rustc-bpWQIb/rustc-1.47.0+dfsg1+llvm/library/std/src/panicking.rs:429
8 libxul.so <webrender::compositor::sw_compositor::SwCompositor as webrender::composite::Compositor>::bind /build/firefox-IXYFrX/firefox-90.0~b12+build1/gfx/wr/webrender/src/compositor/sw_compositor.rs:1253
9 libxul.so webrender::renderer::Renderer::draw_frame /build/firefox-IXYFrX/firefox-90.0~b12+build1/gfx/wr/webrender/src/renderer/mod.rs:4472
Reporter | ||
Comment 1•3 years ago
|
||
Correction, not new in 90.0b12. But there does seem to be an uptick.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 2•3 years ago
|
||
This shows up in the top 10 parent process crash signatures for 90.0.
Can someone take a look?
Comment 3•3 years ago
|
||
(pretty rare for a linux crash to show up that high)
Assignee | ||
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Maybe something went wrong with ubuntu's 90.0 build for 18.04? Most of the reports are from that version (and a few from 16.04).
Comment 5•3 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #4)
Maybe something went wrong with ubuntu's 90.0 build for 18.04? Most of the reports are from that version (and a few from 16.04).
It does crash in Debian (this version is only in unstable, stable has esr) as well.
BTW you can check the build for yourself. The most surefire way to crash it is open a chatguessr map (eg. https://chatguessr.com/map/nuujaka) and zoom in.
Assignee | ||
Comment 6•3 years ago
|
||
(In reply to Jiri Palecek from comment #5)
(In reply to Julien Cristau [:jcristau] from comment #4)
Maybe something went wrong with ubuntu's 90.0 build for 18.04? Most of the reports are from that version (and a few from 16.04).
It does crash in Debian (this version is only in unstable, stable has esr) as well.
BTW you can check the build for yourself. The most surefire way to crash it is open a chatguessr map (eg. https://chatguessr.com/map/nuujaka) and zoom in.
Are you using X11, or are you using Wayland?
Comment 7•3 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #6)
(In reply to Jiri Palecek from comment #5)
(In reply to Julien Cristau [:jcristau] from comment #4)
Maybe something went wrong with ubuntu's 90.0 build for 18.04? Most of the reports are from that version (and a few from 16.04).
It does crash in Debian (this version is only in unstable, stable has esr) as well.
BTW you can check the build for yourself. The most surefire way to crash it is open a chatguessr map (eg. https://chatguessr.com/map/nuujaka) and zoom in.
Are you using X11, or are you using Wayland?
X11 on i386. I've looked through the bugreports and funny thing is, this happens on Linux/x86 and also on OS X (naturally amd64). Linux/amd64 is somehow protected.
Assignee | ||
Comment 8•3 years ago
|
||
Hmm, I've tried to reproduce using the method in comment 5, and I have not been successful regardless of what I try. Are there any other ways to reproduce the issue, possibly more reliably? It's hard to guess what's going on here unless I can catch this in the act.
Assignee | ||
Comment 9•3 years ago
|
||
Alternatively, if you are able to at least reliably reproduce it on your setup with your suggested repro method, could you try using mozregression (https://mozilla.github.io/mozregression/) to narrow down if this is a regression, and which version may have caused it? Note that you may need to force the "gfx.webrender.all" pref to true and "gfx.webrender.software" pref to true in mozregression, as we were potentially changing some default pref values in the recent past so that might influence the results...
Comment 10•3 years ago
|
||
I was also unable to reproduce (though, perhaps not surprising as I'm on X11 + x86_64).
It's hard to imagine a reason this would be x86 specific though (it might be a sampling artifact of the userbase that users who get sw-wr tend to be weighted towards x86, though it seems unlikely to not see a single x64 linux crash I think, even accounting for that).
Are there any other URLs we know of apart from comment 5 that might allow Lee or myself to repro locally?
Updated•3 years ago
|
Comment 11•3 years ago
|
||
I tried reproducing this in a i686 VM and couldn't.
Gmail and whatsapp show up prominently in the crash urls.
Assignee | ||
Comment 12•3 years ago
|
||
It looks like the Ubuntu 32 bit build of 90 is using clang 10.0/rustc 1.47.0. The mozilla official 32 bit build of 90 is using clang 12.0/rustc 1.52.0.
It seems like if, and only if, I use Ubuntu's provided package, I can get it to reproduce sometimes via the chatguessr method. The mozilla official 32 bit build does not reproduce at all.
Can someone who experiences this using the distro package download the mozilla official version, and see if they can reproduce it that way?
Updated•3 years ago
|
Assignee | ||
Comment 13•3 years ago
|
||
Updated•3 years ago
|
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
bugherder |
Comment 16•3 years ago
|
||
I was able to reproduce this crash by building on 18.04 with the ubuntu clang-10 and rustc. Adding -C target-feature=+sse2
to the RUSTCFLAGS made the problem go away. At this point, I'd consider this to be a distro packaging bug.
Updated•3 years ago
|
Assignee | ||
Comment 17•3 years ago
|
||
Comment on attachment 9233613 [details]
Bug 1719232 - Skip render tasks with empty valid rects. r?gw
Beta/Release Uplift Approval Request
- User impact if declined: Frequent high-volume crashing on Ubuntu 32 bit builds.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Fix shouldn't impact our official builds, but works around an issue plaguing Ubuntu's builds.
- String changes made/needed:
Updated•3 years ago
|
Assignee | ||
Comment 18•3 years ago
|
||
We know from testing that the device valid rect itself can sometimes
be empty which produces the symptom that the compositor valid rect
is empty after quantization to i32. So it is sufficient to just check
if that device rect is empty, rather than having to use get_surface_rect
to reproduce the math downstream that produces the compositor valid
rect.
Comment 19•3 years ago
|
||
Comment 20•3 years ago
|
||
bugherder |
Comment 21•3 years ago
|
||
Comment on attachment 9233613 [details]
Bug 1719232 - Skip render tasks with empty valid rects. r?gw
Approved for 91 rc1. I guess we should uplift both patches, right?
Comment 22•3 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 23•3 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #21)
Comment on attachment 9233613 [details]
Bug 1719232 - Skip render tasks with empty valid rects. r?gwApproved for 91 rc1. I guess we should uplift both patches, right?
It is sufficient to just uplift the first patch. The second patch was because Jeff ultimately found us some more proof that a simpler patch would work just as well. I suppose it is better if all releases are using both patches just to make sure we're consistent.
Comment 24•3 years ago
|
||
Thanks. I ended up grafting both.
Description
•