-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sway crashes when interacting with chromium #8194
Comments
bt:
|
TBH, I don't really understand if this is the client sending bad data, or an issue in wlroots. This issue is a bit beyond my understanding of the codebase. |
It's a wlroots issue. If a client sends bad state, it should never crash the entire compositor. |
Can you provide a WAYLAND_DEBUG=1 your-client >client.log 2>&1
# Then reproduce the bug |
Here goes. It's a bit long; I don't have clear reproduction examples, I just resize the window, fullscreen it, move it around a few times, and eventually sway crashes. |
Firefox may trigger this too:
|
I think I am getting the same on 1.10 release. Here's my traces in case it helps:
And the core dump trace:
|
A better reproduction example is sorely needed here. My current approach is to just run chromium, resize it and move it around a lot, and eventually the issue triggers. But this can take between 1 second and several minutes, and produces massive logs. |
I accidentally found a reliable reproducer: A massive window title triggers it, tested with both Firefox and Chromium. Here's two PoC HTML files: black-bar.txt causes the title bar to only show a black bar, and doubling the title size (crash.txt) causes a crash. |
In a tabbed layout, opening |
@minus7 both files in both Firefox and Brave (Chromium based) show only black bar and don't crash on my machine. |
@wooque which version of sway? Can you try moving that Firefox window into a top-level tabbed container? |
Can someone reproduce this with the following wlroots patch and check if my guess at what happens here is correct? diff --git a/types/scene/surface.c b/types/scene/surface.c
index 2aff5af3..a2acf272 100644
--- a/types/scene/surface.c
+++ b/types/scene/surface.c
@@ -1,18 +1,19 @@
#include <assert.h>
#include <stdlib.h>
#include <wlr/types/wlr_alpha_modifier_v1.h>
#include <wlr/types/wlr_compositor.h>
#include <wlr/types/wlr_scene.h>
#include <wlr/types/wlr_fractional_scale_v1.h>
#include <wlr/types/wlr_linux_drm_syncobj_v1.h>
#include <wlr/types/wlr_presentation_time.h>
+#include <wlr/util/log.h>
#include <wlr/util/transform.h>
#include "types/wlr_scene.h"
static void handle_scene_buffer_outputs_update(
struct wl_listener *listener, void *data) {
struct wlr_scene_surface *surface =
wl_container_of(listener, surface, outputs_update);
if (surface->buffer->primary_output == NULL) {
return;
@@ -113,34 +114,42 @@ static void surface_reconfigure(struct wlr_scene_surface *scene_surface) {
pixman_region32_t opaque;
pixman_region32_init(&opaque);
pixman_region32_copy(&opaque, &surface->opaque_region);
int width = state->width;
int height = state->height;
if (!wlr_box_empty(&scene_surface->clip)) {
struct wlr_box *clip = &scene_surface->clip;
+ struct wlr_fbox orig = src_box;
+
int buffer_width = state->buffer_width;
int buffer_height = state->buffer_height;
width = min(clip->width, width - clip->x);
height = min(clip->height, height - clip->y);
wlr_fbox_transform(&src_box, &src_box, state->transform,
buffer_width, buffer_height);
wlr_output_transform_coords(state->transform, &buffer_width, &buffer_height);
src_box.x += (double)(clip->x * buffer_width) / state->width;
src_box.y += (double)(clip->y * buffer_height) / state->height;
src_box.width *= (double)width / state->width;
src_box.height *= (double)height / state->height;
+ if (src_box.x + src_box.width > orig.x + orig.width || src_box.y + src_box.height > orig.y + orig.height) {
+ wlr_log(WLR_ERROR, "!!! src_box has been expanded during clipping !!!");
+ wlr_log(WLR_ERROR, " from %f,%f %fx%f | right = %f bottom = %f", orig.x, orig.y, orig.width, orig.height, orig.x + orig.width, orig.y + orig.height);
+ wlr_log(WLR_ERROR, " to %f,%f %fx%f | right = %f bottom = %f", src_box.x, src_box.y, src_box.width, src_box.height, src_box.x + src_box.width, src_box.y + src_box.height);
+ }
+
wlr_fbox_transform(&src_box, &src_box, wlr_output_transform_invert(state->transform),
buffer_width, buffer_height);
pixman_region32_translate(&opaque, -clip->x, -clip->y);
pixman_region32_intersect_rect(&opaque, &opaque, 0, 0, width, height);
}
if (width <= 0 || height <= 0) {
wlr_scene_buffer_set_buffer(scene_buffer, NULL);
pixman_region32_fini(&opaque); |
1.10 |
Sway renders a black bar or crashes depending on the length of the titlebar. I'd guess that the screen resolution/scale is also relevant here. |
I believe I might be also having this issue, as I crash in the same circumstance. I am currently working on generating a proper and useful coredump. Will build with the posted patch and add more information once I have more results to share. |
Additional detail I have identified: I have used As part of testing I had to exclude that environment configuration, and I cannot replicate the crash without the vulkan renderer. It is possible that it is the cause. |
I had the same crash on 1.10 that I can reproduce by visiting a web page leading to a very long window title as suggested by @minus7, with both Firefox and Chromium. |
I suspect this is related with fractional scaling. On sway
And have those monitors (some information removed to shorten message):
Operations on
Source code and related variables:
I'm not familiar with Wayland stack, but I suspect this is some float point rounding margins during calculating texture decoration, and causing this assert failed. Still, I'm unable to distinguish if this is sway's problem, or wlroot's. Checked some previous issues including @emersion Do you want a copy of coredump, or anything else I can do to help? |
It would be interesting to know if anyone can reproduce this when using a wlroots version with this patch merged: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4981 |
I've just compiled latest masters (sway's 10e50e6 and wlroots' dc7dba8b). The exact same assertion triggers. (Interestingly, for me, black-bar.html causes crash as well) Will probably investigate further what's going wrong over the weekend |
My impression so far is that very wide text renders a black titlebar, and even wider text causes it to crash. The exact definition of "wide" depends on the actual size of the titlebar, hence, for some users a given title causes a crash, but for users of much higher resolutions (with a much larger window) it produces only a black titlebar. |
For the black box on long titles, see: #8586 Not sure if it also fixes the source box assert. |
sway version 1.10-dev-2686afb9 (May 7 2024, branch 'master')
https://paste.sr.ht/~whynothugo/95a3445a0e678c2a642994d7662d5f0357ae1d14
I didn't run sway with
gdb
; will try again and follow-up.Interacting with chromium makes sway crash. Sometimes it's when right clicking, but often times this happens when toggling fullscreen.
I can't find an exact reproducer. Opening a terminal and chromium and moving the windows around / toggling full screen seems to toggle it. Sometimes it happens at the first right-click.
The text was updated successfully, but these errors were encountered: