1719232 - Crash in [@ <webrender::compositor::sw_compositor::SwCompositor as webrender::composite::Compositor>::bind] in distro build because of missing sse2

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Wayne Mery (:wsmwk)]

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

Comment 1

[Wayne Mery (:wsmwk)]

Correction, not new in 90.0b12. But there does seem to be an uptick.

Comment 2

[Julien Cristau [:jcristau] (back April 22)]

This shows up in the top 10 parent process crash signatures for 90.0.

Can someone take a look?

Comment 3

[Julien Cristau [:jcristau] (back April 22)]

(pretty rare for a linux crash to show up that high)

Comment 4

[Julien Cristau [:jcristau] (back April 22)]

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

[Jiri Palecek]

(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.

Comment 6

[Lee Salzman [:lsalzman]]

(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

[Jiri Palecek]

(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.

Comment 8

[Lee Salzman [:lsalzman]]

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.

Comment 9

[Lee Salzman [:lsalzman]]

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

[Glenn Watson [:gw]]

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?

Comment 11

[Jeff Muizelaar [:jrmuizel]]

I tried reproducing this in a i686 VM and couldn't.

Gmail and whatsapp show up prominently in the crash urls.

Comment 12

[Lee Salzman [:lsalzman]]

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?

Comment 13

[Lee Salzman [:lsalzman]]

Attachment: Bug 1719232 - Skip render tasks with empty valid rects. r?gw

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14a14a030d82
Skip render tasks with empty valid rects. r=gw

Comment 15

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/14a14a030d82

Comment 16

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 17

[Lee Salzman [:lsalzman]]

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:

Comment 18

[Lee Salzman [:lsalzman]]

Attachment: Bug 1719232 - Simplify check for empty valid rect. r?jrmuizel

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

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/421a050e91cf
Simplify check for empty valid rect. r=jrmuizel

Comment 20

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/421a050e91cf

Comment 21

[Julien Cristau [:jcristau] (back April 22)]

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

[Julien Cristau [:jcristau] (back April 22)]

https://hg.mozilla.org/releases/mozilla-beta/rev/1d65996b9ae9

Comment 23

[Lee Salzman [:lsalzman]]

(In reply to Julien Cristau [:jcristau] from comment #21)

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?

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

[Julien Cristau [:jcristau] (back April 22)]

Thanks. I ended up grafting both.