1603839 - [WebRender] Crash in [@ mozilla::widget::GtkCompositorWidget::GtkCompositorWidget]

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Andrew McCreight [:mccr8]]

This bug is for crash report bp-a19a0e24-0ab2-4c76-8f1e-5d25f0191211.

Top 10 frames of crashing thread:

0 libxul.so mozilla::widget::GtkCompositorWidget::GtkCompositorWidget widget/gtk/GtkCompositorWidget.cpp:31
1 libxul.so mozilla::widget::CompositorWidgetParent::CompositorWidgetParent widget/gtk/CompositorWidgetParent.cpp:16
2 libxul.so mozilla::layers::CompositorBridgeParent::AllocPCompositorWidgetParent gfx/layers/ipc/CompositorBridgeParent.cpp:2125
3 libxul.so mozilla::layers::PCompositorBridgeParent::OnMessageReceived ipc/ipdl/PCompositorBridgeParent.cpp:1005
4 libxul.so mozilla::layers::PCompositorManagerParent::OnMessageReceived ipc/ipdl/PCompositorManagerParent.cpp:197
5 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2209
6 libxul.so mozilla::ipc::MessageChannel::RunMessage ipc/glue/MessageChannel.cpp:1973
7 libxul.so mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:2004
8 libxul.so MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:523
9 libxul.so base::MessagePumpDefault::Run ipc/chromium/src/base/message_pump_default.cc:35

There's a handful of crashes with this signature on Nightly, and they are mostly crashing on this assert: MOZ_RELEASE_ASSERT(aWindow) (We're running on Wayland and but without valid nsWindow.)

Comment 1

[Rob Wu [:robwu]]

I encountered this crash (I don't know what happened, as it was a backlogged crash report from this week from Nightly), and I am definitely not running Wayland (just x11).

Not sure if relevant, but: I noticed the crash report when I wanted to investigate why Firefox showed the "Restart required" tab on startup of a new instance in a new profile. The browser UI appears but I am unable to load any tabs, and stderr shows the following:

Maximum number of clients reachedUnable to init server: Could not connect: Connection refused

(/usr/lib/firefox/firefox:1631039): Gtk-WARNING **: 10:45:30.701: cannot open display: :0

Comment 2

[Martin Stránský [:stransky] (ni? me)]

(In reply to Rob Wu [:robwu] from comment #1)

I encountered this crash (I don't know what happened, as it was a backlogged crash report from this week from Nightly), and I am definitely not running Wayland (just x11).

Not sure if relevant, but: I noticed the crash report when I wanted to investigate why Firefox showed the "Restart required" tab on startup of a new instance in a new profile. The browser UI appears but I am unable to load any tabs, and stderr shows the following:

It's because your Firefox installations was updated on background and you're running old version.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Seems to be WR related.

Comment 4

[Rob Wu [:robwu]]

(In reply to Martin Stránský [:stransky] from comment #2)

It's because your Firefox installations was updated on background and you're running old version.

That is not the case. I use nightly without autoupdates, and there has not been an update since the startup.
Those are the update dates:

[2020-03-23T18:39:58+0100] [ALPM] upgraded firefox-nightly (75.0a1.20200309-1 -> 76.0a1.20200323-1)
[2020-03-25T13:55:28+0100] [ALPM] upgraded firefox-nightly (76.0a1.20200323-1 -> 76.0a1.20200325-1)
[2020-04-20T01:12:56+0200] [ALPM] upgraded firefox-nightly (76.0a1.20200325-1 -> 77.0a1.20200419-1)

The crash report is bp-cd09b47c-aa90-428b-a444-c7e5f0200415. The report was submitted on 2020-04-15, the crash happened a day prior.

Based on the stderr output that I shared in comment 1 and the stack trace, I think that it is more likely that this had happened:

• GtkCompositorWidget is called with aWindow = nullptr.
• mXDisplay = XOpenDisplay(aInitData.XDisplayString().get()); is nullptr, because it is unable to open a connection to the X server (I have hundreds of browser tabs scattered over multiple instances of Firefox and Chromium).
• Because mXDisplay is nullptr, and Firefox was compiled with MOZ_WAYLAND=1, the assertion is triggered.

Again, I am NOT running Wayland. The assertion message is inaccurate, or a runtime check is missing (maybe && !IsWaylandDisabled() ?).

Comment 5

[Martin Stránský [:stransky] (ni? me)]

(In reply to Rob Wu [:robwu] from comment #4)

Based on the stderr output that I shared in comment 1 and the stack trace, I think that it is more likely that this had happened:

• GtkCompositorWidget is called with aWindow = nullptr.
• mXDisplay = XOpenDisplay(aInitData.XDisplayString().get()); is nullptr, because it is unable to open a connection to the X server (I have hundreds of browser tabs scattered over multiple instances of Firefox and Chromium).
• Because mXDisplay is nullptr, and Firefox was compiled with MOZ_WAYLAND=1, the assertion is triggered.

Again, I am NOT running Wayland. The assertion message is inaccurate, or a runtime check is missing (maybe && !IsWaylandDisabled() ?).

Thanks a lot for the analysis here, I'll look at it. Also I wonder why it fails to open a new connection to X server in this case..when that happens you can expect more problems soon.

Comment 6

[Rob Wu [:robwu]]

(In reply to Martin Stránský [:stransky] from comment #5)

Also I wonder why it fails to open a new connection to X server in this case..

I think that I've reached the maximum number of clients due the number of browser/windows/tabs that I had opened. To easily reproduce yourself, I suppose that you could create a C program that repeatedly calls XOpenDisplay until it returns NULL (should happen in about a few hundred iterations). After reaching that point, let the program wait for user input before calling XCloseDisplay on exit.
Then start Firefox, run your C program, trigger the code path that goes through the stack in this bug report and you should be able to reproduce it.

A search for "Maximum number of clients reached" on the internet (e.g. with DuckDuckGo) also shows many instances of this issue over past few years (also including users of Firefox).

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1603839 [Linux] Explicitly set Wayland/X11 backend for GtkCompositorWidget, r?jhorak

Comment 8

[Martin Stránský [:stransky] (ni? me)]

The patch here does not fix the cause (missing X display connection) but explicitly states X11/Wayland backend so we won't use wayland backend when we're missing X display connection.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d74a981c9b748919aa06b3fcbdae6c17b0adb206

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/880f56e1656b
[Linux] Explicitly set Wayland/X11 backend for GtkCompositorWidget, r=jhorak

Comment 11

[Arthur Iakab [arthur_iakab]]

Backed out changeset 880f56e1656b (bug 1603839) for causing build bustages on GtkCompositorWidget.h

Backout revision https://hg.mozilla.org/integration/autoland/rev/97746752b28722cf211936074133ae771f760fec

Failed push https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=880f56e1656bd0788c6d9fcf1ad85cae485c03b1

Failure logs https://treeherder.mozilla.org/logviewer.html#?job_id=298987136&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=298987119&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=298987165&repo=autoland

Martin can you please take a look?

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Updated, Thanks.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/419f1b2c6b40
[Linux] Explicitly set Wayland/X11 backend for GtkCompositorWidget, r=jhorak

Comment 14

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/419f1b2c6b40