1802327 - Crash in [@ wl_log] (xdg_activation_v1_activate)

Status: RESOLVED FIXED

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

Description

[Jan Alexander Steffens [:heftig]]

Crash report: https://crash-stats.mozilla.org/report/index/49182886-4264-453b-9444-bbe1b0221124

MOZ_CRASH Reason:

error marshalling arguments for activate (signature so): null value passed for arg 1

Top 10 frames of crashing thread:

0  libxul.so  MOZ_Crash  mfbt/Assertions.h:261
0  libxul.so  mozilla::widget::WlCrashHandler  widget/gtk/nsWaylandDisplay.cpp:275
1  libwayland-client.so.0  wl_log  /usr/src/debug/wayland-1.21.0/src/wayland-util.c:449
2  libwayland-client.so.0  wl_proxy_marshal_array_flags  /usr/src/debug/wayland-1.21.0/src/wayland-client.c:849
3  libwayland-client.so.0  wl_proxy_marshal_flags  /usr/src/debug/wayland-1.21.0/src/wayland-client.c:791
4  libgdk-3.so.0  xdg_activation_v1_activate  /usr/src/debug/gtk3/build/gdk/wayland/xdg-activation-v1-client-protocol.h:235
4  libgdk-3.so.0  gdk_wayland_window_focus  /usr/src/debug/gtk3/gtk/gdk/wayland/gdkwindow-wayland.c:3876
5  libxul.so  nsWindow::SetUserTimeAndStartupTokenForActivatedWindow  widget/gtk/nsWindow.cpp:3047
6  libxul.so  nsWindow::NativeShow  widget/gtk/nsWindow.cpp:6618
7  libxul.so  nsWindow::Show  widget/gtk/nsWindow.cpp:963

This was a sudden crash using the browser. I don't remember what exactly I did at the time.

The code here is new in GTK 3.24.35. I've already filed a bug upstream and a maintainer responded:

This corresponds to https://gitlab.gnome.org/GNOME/gtk/-/blob/5beaf8d0/gdk/wayland/gdkwindow-wayland.c#L3876, and the argument being NULL seems to be the last one (impl->display_server.wl_surface), it sounds plausible that it was already NULL when entering the function, which would mean that a hidden/destroying window was attempting to get focus.

Looking at the full backtrace at https://crash-stats.mozilla.org/report/index/49182886-4264-453b-9444-bbe1b0221124, it does seem Firefox is attempting to set the startup notification token while showing the window, and it does seem to do that before gdk_window_show() could be called on it (https://hg.mozilla.org/mozilla-central/file/c300f1dba775b816820c22e7eed5ae860c236754/widget/gtk/nsWindow.cpp#l6618), i.e. at a time it does not have a wl_surface yet.

Probably crashing is harsh, but this switched order of events should likely be handled on the Firefox side, GTK at best all could do is warning and ignoring the activation request.

GTK 3.24.35
GNOME Shell 43.1
Arch Linux

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly (startup)

:stransky, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Comment 2

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

Attachment: Bug 1802327 [Linux] Activate nsWindow by SetUserTimeAndStartupTokenForActivatedWindow() after gtk_widget_show() to make sure it's visible r?emilio

Comment 3

[The Anarcat]

i migrated from Xorg/i3 to Wayland/sway recently and Firefox ESR (102.5) has become much more unstable than before. i found this bug report from my crash report:

https://crash-stats.mozilla.org/report/index/437d0035-ee78-44d1-b4a2-a914c0221129

happy to test fixes if/when they become available.

i have also had other crashes that just make firefox blink out of existence without submitting a crash report at all, which is worrisome...

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/97e605f8f61f
[Linux] Activate nsWindow by SetUserTimeAndStartupTokenForActivatedWindow() after gtk_widget_show() to make sure it's visible r=emilio

Comment 5

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/97e605f8f61f

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Not sure if this is something we're going to want to uplift or not. It grafts cleanly to 108 but would need some rebasing for ESR102.

Comment 7

[Dianna Smith [:diannaS]]

:stransky There still seems to be some crashes even after the patch landed in nightly.

Comment 8

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

(In reply to Dianna Smith [:diannaS] from comment #7)

:stransky There still seems to be some crashes even after the patch landed in nightly.

Can you attach crash ID?

Comment 9

[Dianna Smith [:diannaS]]

Most recently on nightly was Crash ID: b494c251-132e-47e2-ad80-09c9d0221206

Comment 10

[Robert Mader [:rmader]]

(In reply to Dianna Smith [:diannaS] from comment #9)

Most recently on nightly was Crash ID: b494c251-132e-47e2-ad80-09c9d0221206

This looks like a different crash to me - wl_log is pretty much a catch all for a number of different possible crashes.

The message is "unknown object (4278190085)" and happens in Mesa (21.2.6) on eglSwapBuffersWithDamage() - unlikely to have anything to do with xdg_activation_v1_activate. In fact, to me this looks like a rare driver bug and may or may not have been fixed upstream already 🤷

Comment 11

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

Yeah, not related. Looks like multi-threading bug, you see a crash from Render thread. But definitely something we should look at.

Comment 12

[Robert Mader [:rmader]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #11)

Yeah, not related. Looks like multi-threading bug, you see a crash from Render thread. But definitely something we should look at.

Probably noteworthy: the crashing setup uses the i965 driver on Mesa 21.2 - on Ubuntu 22.04. The later shipped with Mesa 22.0, which removed that driver (and all other classic DRI drivers). So we are most likely dealing with a frankenstein setup where somebody installed an old Mesa version (or did an incomplete update). Which would perfectly explain a message like "unknown object (4278190085)". So probably nothing we can do anything about.

Comment 13

[Dianna Smith [:diannaS]]

got it, thank you for taking a look! Please let me know if this is something we want to uplift to fx108 for the next Release candidate. If its better if it just rides the trains, you can mark firefox108 as wontfix.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Copying crash signatures from duplicate bugs.