Skip to content
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

Open
WhyNotHugo opened this issue Jun 1, 2024 · 23 comments
Open

sway crashes when interacting with chromium #8194

WhyNotHugo opened this issue Jun 1, 2024 · 23 comments
Labels
bug Not working as intended
Milestone

Comments

@WhyNotHugo
Copy link
Contributor

WhyNotHugo commented Jun 1, 2024

  • Sway Version:

sway version 1.10-dev-2686afb9 (May 7 2024, branch 'master')

  • Debug Log:

https://paste.sr.ht/~whynothugo/95a3445a0e678c2a642994d7662d5f0357ae1d14

  • Stack Trace:

I didn't run sway with gdb; will try again and follow-up.

  • Description:

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.

@WhyNotHugo WhyNotHugo added the bug Not working as intended label Jun 1, 2024
@WhyNotHugo
Copy link
Contributor Author

bt:

#1  0x00007ffff7fa9845 in raise (sig=sig@entry=6) at src/signal/raise.c:11
        set = {__bits = {0, 206158430224, 140737488343872, 140737488343680, 1027, 1, 93824993928152, 93824993928080, 93824993928384, 23, 12020, 140737353616819, 140737488344048, 140737488344064, 140737488344048, 0}}
        ret = 0
#2  0x00007ffff7f78c21 in abort () at src/exit/abort.c:11
No locals.
#3  0x00007ffff7f78ccf in __assert_fail (expr=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>) at src/exit/assert.c:7
No locals.
#4  0x000055555568aedd in wlr_render_pass_add_texture (render_pass=0x7fffe9856860, options=0x7fffffffd420) at ../subprojects/wlroots/render/pass.c:23
        box = 0x7fffffffd428
        __func__ = "wlr_render_pass_add_texture"
#5  0x000055555562f57c in scene_entry_render (entry=0x7fffe8a8bff8, data=0x7fffffffd650) at ../subprojects/wlroots/types/scene/wlr_scene.c:1232
        texture = 0x7fffe9855bb0
        scene_rect = 0x55555572d8c0 <surface_addon_impl>
        scene_buffer = 0x7fffe8d84560
        transform = WL_OUTPUT_TRANSFORM_NORMAL
        sample_event = {output = 0x7fffe95c12e0, direct_scanout = 56}
        node = 0x7fffe8d84560
        render_region = {extents = {x1 = 0, y1 = 45, x2 = 1897, y2 = 1027}, data = 0x0}
        dst_box = {x = 0, y = 47, width = 1896, height = 979}
        opaque = {extents = {x1 = 0, y1 = 45, x2 = 1897, y2 = 1027}, data = 0x7fffe98246f0}
        __func__ = "scene_entry_render"
#6  0x000055555563135c in wlr_scene_output_build_state (scene_output=0x7fffe95c12e0, state=0x7fffffffd6d0, options=0x7fffffffd590) at ../subprojects/wlroots/types/scene/wlr_scene.c:1923
        entry = 0x7fffe8a8bff8
        i = 1
        default_options = {timer = 0x0, color_transform = 0x0, swapchain = 0x0}
        timer = 0x0
        start_time = {tv_sec = 2, tv_nsec = 140737115910664}
        output = 0x7fffe994b6b0
        debug_damage = WLR_SCENE_DEBUG_DAMAGE_NONE
        render_data = {transform = WL_OUTPUT_TRANSFORM_NORMAL, scale = 1.5, logical = {x = 0, y = 0, width = 1280, height = 720}, trans_width = 1920, trans_height = 1080, output = 0x7fffe95c12e0, render_pass = 0x7fffe9856860, 
          damage = {extents = {x1 = 0, y1 = 45, x2 = 1897, y2 = 1027}, data = 0x0}}
        resolution_width = 1920
        resolution_height = 1080
        list_con = {box = {x = 0, y = 0, width = 1280, height = 720}, render_list = 0x7fffe95c1418, calculate_visibility = true}
        list_data = 0x7fffe8a8bfe0
        list_len = 21
        now = {tv_sec = 12507516256, tv_nsec = 140737115910648}
        scanout = false
        swapchain = 0x7fffea0ae870
        buffer = 0x7fffe9432890
        __func__ = "wlr_scene_output_build_state"
        render_pass = 0x7fffe9856860
        background = {extents = {x1 = 0, y1 = 46, x2 = 1897, y2 = 1027}, data = 0x7fffe98240b0}
#7  0x000055555563074a in wlr_scene_output_commit (scene_output=0x7fffe95c12e0, options=0x0) at ../subprojects/wlroots/types/scene/wlr_scene.c:1683
        ok = false
        state = {committed = 2, allow_reconfiguration = false, damage = {extents = {x1 = 0, y1 = 45, x2 = 1897, y2 = 1027}, data = 0x0}, enabled = false, scale = 0, transform = WL_OUTPUT_TRANSFORM_NORMAL, 
          adaptive_sync_enabled = false, render_format = 0, subpixel = WL_OUTPUT_SUBPIXEL_UNKNOWN, buffer = 0x0, tearing_page_flip = false, mode_type = WLR_OUTPUT_STATE_MODE_FIXED, mode = 0x0, custom_mode = {width = 0, 
            height = 0, refresh = 0}, gamma_lut = 0x0, gamma_lut_size = 0, layers = 0x0, layers_len = 0}
#8  0x00005555555945b1 in output_repaint_timer_handler (data=0x7fffe947f310) at ../sway/desktop/output.c:272
        output = 0x7fffe947f310
#9  0x0000555555594753 in handle_frame (listener=0x7fffe947f460, user_data=0x7fffe994b6b0) at ../sway/desktop/output.c:326
        output = 0x7fffe947f310
        msec_until_refresh = 0
        delay = 0
        data = {when = {tv_sec = 0, tv_nsec = 140737488345248}, msec_until_refresh = 2, output = 0x7fffffffd8c8}
#10 0x00007ffff7a9c61d in wl_signal_emit_mutable () from /usr/lib/libwayland-server.so.0
No symbol table info available.
#11 0x00005555556282e3 in wlr_output_send_frame (output=0x7fffe994b6b0) at ../subprojects/wlroots/types/output/output.c:753
No locals.
#12 0x0000555555628327 in schedule_frame_handle_idle_timer (data=0x7fffe994b6b0) at ../subprojects/wlroots/types/output/output.c:761
        output = 0x7fffe994b6b0
#13 0x00007ffff7a9d935 in wl_event_loop_dispatch_idle () from /usr/lib/libwayland-server.so.0
No symbol table info available.
#14 0x00007ffff7a9dae8 in wl_event_loop_dispatch () from /usr/lib/libwayland-server.so.0
No symbol table info available.
#15 0x00007ffff7a9df17 in wl_display_run () from /usr/lib/libwayland-server.so.0
No symbol table info available.
#16 0x0000555555590bae in server_run (server=0x555555737120 <server>) at ../sway/server.c:493
No locals.
#17 0x000055555558f304 in main (argc=1, argv=0x7fffffffdc58) at ../sway/main.c:373
        verbose = false
        debug = false
        validate = false
        config_path = 0x0
        c = -1

@WhyNotHugo
Copy link
Contributor Author

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.

@Nefsen402
Copy link
Member

It's a wlroots issue. If a client sends bad state, it should never crash the entire compositor.

@emersion
Copy link
Member

Can you provide a WAYLAND_DEBUG=1 log of your client?

WAYLAND_DEBUG=1 your-client >client.log 2>&1
# Then reproduce the bug

@WhyNotHugo
Copy link
Contributor Author

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.

client.log

@OkamiW
Copy link

OkamiW commented Nov 13, 2024

Firefox may trigger this too:

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  ? in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
#2  ? in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  ? in __GI_abort () at abort.c:79
#4  ? in __assert_fail_base
    (fmt=? "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=? "box->x >= 0 && box->y >= 0 && box->x + box->width <= options->texture->width && box->y + box->height <= options->texture->height", file=file@entry=? "render/pass.c", line=line@entry=23, function=function@entry=? <__PRETTY_FUNCTION__.1> "wlr_render_pass_add_texture") at assert.c:94
#5  ? in __assert_fail
    (assertion=? "box->x >= 0 && box->y >= 0 && box->x + box->width <= options->texture->width && box->y + box->height <= options->texture->height", file=? "render/pass.c", line=23, function=? <__PRETTY_FUNCTION__.1> "wlr_render_pass_add_texture") at assert.c:103
#6  ? in wlr_render_pass_add_texture (render_pass=?, options=?) at ../subprojects/wlroots/render/pass.c:23
#7  ? in scene_entry_render (entry=?, data=?) at ../subprojects/wlroots/types/scene/wlr_scene.c:1388
#8  ? in wlr_scene_output_build_state (scene_output=?, state=?, options=?) at ../subprojects/wlroots/types/scene/wlr_scene.c:2192
#9  ? in output_repaint_timer_handler (data=?) at ../sway/desktop/output.c:283
#10 ? in handle_frame (listener=?, user_data=?) at ../sway/desktop/output.c:355
#11 ? in wl_signal_emit_mutable (signal=<optimized out>, data=?) at ../wayland-1.23.1/src/wayland-server.c:2314
#12 ? in wlr_output_send_frame (output=?) at ../subprojects/wlroots/types/output/output.c:787
#13 ? in handle_page_flip (fd=10, seq=0, tv_sec=29181, tv_usec=482033, crtc_id=57, data=?) at ../subprojects/wlroots/backend/drm/drm.c:2001
#14 ? in drmHandleEvent (fd=10, evctx=?) at ../libdrm-2.4.123/xf86drmMode.c:1070
#15 ? in handle_drm_event (fd=10, mask=1, data=?) at ../subprojects/wlroots/backend/drm/drm.c:2013
#16 ? in wl_event_loop_dispatch (loop=?, timeout=<optimized out>, timeout@entry=-1) at ../wayland-1.23.1/src/event-loop.c:1105
#17 ? in wl_display_run (display=?) at ../wayland-1.23.1/src/wayland-server.c:1530
#18 ? in server_run (server=? <server>) at ../sway/server.c:508
#19 ? in main (argc=2, argv=?) at ../sway/main.c:373

@andreesteve
Copy link

I think I am getting the same on 1.10 release. Here's my traces in case it helps:

libpng warning: sRGB: out of place
libpng warning: sRGB: out of place
libpng warning: sRGB: out of place
warn: quirks.c:80: applying wl_surface_damage_buffer() workaround for Sway
00:04:24.474 [ERROR] [wlr] [xwayland/xwm.c:1192] Failed to get window property
00:04:54.715 [ERROR] [wlr] [xwayland/xwm.c:1192] Failed to get window property
libpng warning: sRGB: out of place
libpng warning: sRGB: out of place
00:06:21.960 [ERROR] [sway/sway_text_node.c:110] cairo_image_surface_create failed: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
00:06:21.960 [ERROR] [sway/sway_text_node.c:110] cairo_image_surface_create failed: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
sway: render/pass.c:23: wlr_render_pass_add_texture: Assertion `box->x >= 0 && box->y >= 0 && box->x + box->width <= options->texture->width && box->y + box->height <= options->texture->height' failed.
(EE)[2024-11-15 10:59:33.889] [error] Scratchpad: Unable to receive IPC header
 failed to read Wayland events: Connection reset by peer

And the core dump trace:

Stack trace of thread 723:
#0  0x000077dc2cb723f4 n/a (libc.so.6 + 0x963f4)
#1  0x000077dc2cb19120 raise (libc.so.6 + 0x3d120)
#2  0x000077dc2cb004c3 abort (libc.so.6 + 0x244c3)
#3  0x000077dc2cb003df n/a (libc.so.6 + 0x243df)
#4  0x000077dc2cb11177 __assert_fail (libc.so.6 + 0x35177)
#5  0x000077dc2cd8440e wlr_render_pass_add_texture (libwlroots-0.18.so + 0x2b40e)
#6  0x000077dc2cdc5f91 wlr_scene_output_build_state (libwlroots-0.18.so + 0x6cf91)
#7  0x000058e56d1f6e0e n/a (sway + 0x1ee0e)
#8  0x000058e56d1f7057 n/a (sway + 0x1f057)
#9  0x000077dc2ce7747e wl_signal_emit_mutable (libwayland-server.so.0 + 0x847e)
#10 0x000077dc2ce78efc wl_event_loop_dispatch_idle (libwayland-server.so.0 + 0x9efc)
#11 0x000077dc2ce79177 wl_event_loop_dispatch (libwayland-server.so.0 + 0xa177)
#12 0x000077dc2ce7b1f7 wl_display_run (libwayland-server.so.0 + 0xc1f7)
#13 0x000058e56d1e7dd2 n/a (sway + 0xfdd2)
#14 0x000077dc2cb01e08 n/a (libc.so.6 + 0x25e08)
#15 0x000077dc2cb01ecc __libc_start_main (libc.so.6 + 0x25ecc)
#16 0x000058e56d1e8275 n/a (sway + 0x10275)

@WhyNotHugo
Copy link
Contributor Author

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.

@minus7
Copy link
Contributor

minus7 commented Jan 19, 2025

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.

@WhyNotHugo
Copy link
Contributor Author

In a tabbed layout, opening black-bar.html in Firefox immediately crashed sway for me. It didn't crash sway in a vertical split.

@wooque
Copy link

wooque commented Jan 19, 2025

@minus7 both files in both Firefox and Brave (Chromium based) show only black bar and don't crash on my machine.

@WhyNotHugo
Copy link
Contributor Author

@wooque which version of sway? Can you try moving that Firefox window into a top-level tabbed container?

@vyivel
Copy link
Member

vyivel commented Jan 19, 2025

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);

@wooque
Copy link

wooque commented Jan 19, 2025

@WhyNotHugo

1.10
here is the screenshot, only black bar shown, no crashing.

Image

@WhyNotHugo
Copy link
Contributor Author

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.

@cbondurant
Copy link

I believe I might be also having this issue, as I crash in the same circumstance.
My best way to reproduce the behavior is with the Reaper DAW.
I have a 100% replication rate across 5-6 separate attempts so far when I open ReaSamplOmatic5000 in a plugin window, float the window, and then attempt to increase its width in any amount.

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.

@cbondurant
Copy link

Additional detail I have identified: I have used WLR_RENDERER=vulkan on my system for a long time now, because at the time I enabled it, I had been dealing with horrible flickering in certain applications.

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.

@OlivierNicole
Copy link

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.

@davendu
Copy link

davendu commented Feb 14, 2025

I suspect this is related with fractional scaling. On sway 1.10.1, my screen is configured like this:

# 3 displays
output HDMI-A-1 scale 1.5 
output DP-1     scale 1.5 
output DP-2     scale 1.5 transform 270

output DP-1     pos 1440 1440
output DP-2     pos 0     0
output HDMI-A-1 pos 1440  0

And have those monitors (some information removed to shorten message):

> swaymsg -t get_outputs
Output HDMI-A-1
  Current mode: 3840x2160 @ 60.000 Hz
  Position: 1440,0
  Scale factor: 1.500000
  Scale filter: linear
  Subpixel hinting: unknown
  Transform: normal
  Adaptive sync: disabled
  Allow tearing: no
  Available modes: ...

Output DP-2
  Current mode: 3840x2160 @ 59.997 Hz
  Position: 0,0
  Scale factor: 1.500000
  Scale filter: linear
  Subpixel hinting: unknown
  Transform: 270
  Adaptive sync: disabled
  Allow tearing: no
  Available modes: ...

Output DP-1
  Current mode: 3840x2160 @ 59.997 Hz
  Position: 1440,1440
  Scale factor: 1.500000
  Scale filter: linear
  Subpixel hinting: unknown
  Transform: normal
  Adaptive sync: disabled
  Allow tearing: no
  Available modes: ...

Operations on DP-1 is have a higher risk of causing crash with following stack:

...
#5  0x00007fbbf54ddc30 in __assert_fail (assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=<optimized out>) at assert.c:127
#6  0x00007fbbf576040e in wlr_render_pass_add_texture (render_pass=0x56a2a7a478d0, options=0x7fff490e3470) at ../wlroots-0.18.2/render/pass.c:23
#7  0x00007fbbf57a2311 in scene_entry_render (entry=0x56a2a7aed3b8, data=0x7fff490e3420) at ../wlroots-0.18.2/types/scene/wlr_scene.c:1270
#8  wlr_scene_output_build_state (scene_output=0x56a2a6b85cc0, state=state@entry=0x7fff490e3560, options=<optimized out>, options@entry=0x7fff490e3540) at ../wlroots-0.18.2/types/scene/wlr_scene.c:1959
#9  0x000056a29e601060 in output_repaint_timer_handler (data=data@entry=0x56a2a6bc3430) at ../sway/sway/desktop/output.c:285
...

Source code and related variables:

(gdb) list
18			const struct wlr_render_texture_options *options) {
19		// make sure the texture source box does not try and sample outside of the
20		// texture
21		if (!wlr_fbox_empty(&options->src_box)) {
22			const struct wlr_fbox *box = &options->src_box;
23			assert(box->x >= 0 && box->y >= 0 &&
24				box->x + box->width <= options->texture->width &&
25				box->y + box->height <= options->texture->height);
26		}
27	
(gdb) print *box
$2 = {
  x = 24,
  y = 15.008103727714749,
  width = 2136,
  height = 910.99189627228532
}
(gdb) print *options->texture
$3 = {
  impl = 0x7fbbf583f540 <texture_impl.lto_priv>,
  width = 0x870,
  height = 0x39e,
  renderer = 0x56a2a67487d0
}
(gdb) print 15.008103727714749+910.99189627228532
$4 = 926.00000000000011
(gdb) print 926
$5 = 0x39e

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 wlroots/wlroots #3766, #3790 but I don't think they are related with this bug.

@emersion Do you want a copy of coredump, or anything else I can do to help?

@ifreund
Copy link
Member

ifreund commented Feb 18, 2025

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

@DanShaders
Copy link

DanShaders commented Feb 19, 2025

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

@WhyNotHugo
Copy link
Contributor Author

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.

@emersion emersion modified the milestones: 1.10.1, 1.10.2 Feb 21, 2025
@kennylevinsen
Copy link
Member

For the black box on long titles, see: #8586

Not sure if it also fixes the source box assert.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Not working as intended
Development

No branches or pull requests