Closed Bug 1802327 Opened 13 days ago Closed 6 days ago

Crash in [@ wl_log] (xdg_activation_v1_activate)

Categories

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

Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
109 Branch
Tracking Status
firefox-esr102 --- fix-optional
firefox107 --- wontfix
firefox108 --- fix-optional
firefox109 --- fixed

People

(Reporter: heftig, Assigned: stransky)

References

(Blocks 1 open bug)

Details

(Keywords: crash, topcrash, topcrash-startup)

Crash Data

Attachments

(1 file)

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

Priority: -- → P2

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.

Flags: needinfo?(stransky)
Assignee: nobody → stransky
Status: NEW → ASSIGNED
Flags: needinfo?(stransky)

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

Pushed by stransky@redhat.com:
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
Status: ASSIGNED → RESOLVED
Closed: 6 days ago
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch

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.

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

Flags: needinfo?(stransky)

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

Flags: needinfo?(stransky) → needinfo?(dsmith)
Flags: needinfo?(dsmith)

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

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

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

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.

You need to log in before you can comment on or make changes to this bug.