Crash in [@ wl_log] (xdg_activation_v1_activate)
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
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
Assignee | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
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.
Assignee | ||
Comment 2•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 3•2 years ago
|
||
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 5•2 years ago
|
||
bugherder |
Comment 6•2 years ago
|
||
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•2 years ago
|
||
:stransky There still seems to be some crashes even after the patch landed in nightly.
Assignee | ||
Comment 8•2 years ago
|
||
(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•2 years ago
|
||
Most recently on nightly was Crash ID: b494c251-132e-47e2-ad80-09c9d0221206
Comment 10•2 years ago
|
||
(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 🤷
Assignee | ||
Comment 11•2 years ago
|
||
Yeah, not related. Looks like multi-threading bug, you see a crash from Render thread. But definitely something we should look at.
Comment 12•2 years ago
|
||
(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•2 years ago
|
||
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•2 years ago
|
||
Copying crash signatures from duplicate bugs.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•