sway crashes when interacting with chromium

[WhyNotHugo]

• 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]

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]

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]

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

[emersion]

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]

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]

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]

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]

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]

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]

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]

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

[WhyNotHugo]

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

[vyivel]

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]

@WhyNotHugo

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

[WhyNotHugo]

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]

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]

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]

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]

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]

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]

I've just compiled latest masters (sway's 10e50e6b 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]

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.

[kennylevinsen]

For the black box on long titles, see: https://github.com/swaywm/sway/pull/8586

Not sure if it also fixes the source box assert.

[xtsm]

JFYI if you urgently need to mitigate this without rebuilding sway: switching the browser window into floating mode (mod+shift+space by default) seems to work.

[marienz]

I'm triggering what I'm currently assuming is the same crash by opening a print preview window in Chrome (using its wayland Ozone backend), using Sway 1.10.1 and wlroots 0.18.2 with the patch from https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4981 applied. Same "cairo_image_surface_create failed", then:

(gdb) bt
(assert stuff omitted)
#5  0x00007f24feecd692 in __assert_fail
    (assertion=0x7f24ff8c3328 "box->x >= 0 && box->y >= 0 && box->x + box->width <= options->texture->width && box->y + box->height <= options->texture->height", file=0x7f24ff8c32e0 "render/pass.c", line=23, function=0x7f24ff8c3410 <__PRETTY_FUNCTION__.1> "wlr_render_pass_add_texture") at ./assert/assert.c:105
#6  0x00007f24ff80765d in wlr_render_pass_add_texture (render_pass=0x55cff2179200, options=0x7ffe85840170) at ../subprojects/wlroots/render/pass.c:23
#7  0x00007f24ff844e96 in scene_entry_render (entry=0x55cff2159cf8, data=0x7ffe85840440) at ../subprojects/wlroots/types/scene/wlr_scene.c:1270
#8  0x00007f24ff846af9 in wlr_scene_output_build_state (scene_output=0x55cff1afb5d0, state=0x7ffe85840580, options=0x7ffe85840600) at ../subprojects/wlroots/types/scene/wlr_scene.c:1959
#9  0x000055cfb3f91122 in output_repaint_timer_handler (data=0x55cff1aeabe0) at ../sway/desktop/output.c:285
#10 0x000055cfb3f9146d in handle_frame (listener=0x55cff1aead30, user_data=0x55cff1b0d4b0) at ../sway/desktop/output.c:373
#11 0x00007f24ff121b4c in wl_signal_emit_mutable () at /lib/x86_64-linux-gnu/libwayland-server.so.0
#12 0x00007f24ff83e10d in wlr_output_send_frame (output=0x55cff1b0d4b0) at ../subprojects/wlroots/types/output/output.c:753
#13 0x00007f24ff81e68b in handle_page_flip (fd=12, seq=488118, tv_sec=8164, tv_usec=155314, crtc_id=100, data=0x55cff21818d0) at ../subprojects/wlroots/backend/drm/drm.c:2100
#14 0x00007f24ff65fc47 in drmHandleEvent () at /lib/x86_64-linux-gnu/libdrm.so.2
#15 0x00007f24ff81e6de in handle_drm_event (fd=12, mask=1, data=0x55cff0a72000) at ../subprojects/wlroots/backend/drm/drm.c:2112
#16 0x00007f24ff123cf2 in wl_event_loop_dispatch () at /lib/x86_64-linux-gnu/libwayland-server.so.0
#17 0x00007f24ff121525 in wl_display_run () at /lib/x86_64-linux-gnu/libwayland-server.so.0
#18 0x000055cfb3f8d4c7 in server_run (server=0x55cfb400dce0 <server>) at ../sway/server.c:501
#19 0x000055cfb3f8bc33 in main (argc=1, argv=0x7ffe85841068) at ../sway/main.c:374

(gdb) f 6
...
(gdb) p *box
$1 = {x = 0, y = 0, width = 3820, height = 36}
(gdb) p *options->texture
$2 = {impl = 0x7f24ff908fe0 <texture_impl>, width = 374, height = 36, renderer = 0x55cff0c50f00}

(height matches, box width much larger than texture width).

I have a 3840x2400 output with scale factor 2, but this doesn't obviously look like something scale-factor-related. My titlebars are (based on counting pixels in a screenshot) 52 pixels tall, but there's a bunch of padding around the titlebar text so if there's a texture not including that text a 36 pixel height for that seems plausible. (Also, options->dst_box has x=10, y=8, and width and height same as src_box: assuming that's relative to the output that'd fit with it being titlebar text).

Applying the logging patch from https://github.com/swaywm/sway/issues/8194#issuecomment-2600936550 (on top of the other wlroots patch, it looks like the added logging still makes sense), that logging does not trigger.

Haven't wrapped my head around what all this code does yet...

Looking at sway_text_node_set_max_width, there's an update_source_box call before the render_backing_buffer call (here). render_backing_buffer contains its own update_source_box call here, which is paired with a wlr_scene_buffer_set_buffer call. Judging by that previous logged error, we're exiting render_backing_buffer early (here).

Again, don't know what this code does yet, but that seemed suspicious... I tried commenting out the update_source_box call before the render_backing_buffer call (reasoning that as long as render_backing_buffer doesn't fail it'll call update_source_box again anyway and at first glance that'd plausibly be early enough) and now I'm no longer crashing but I get a very horizontally stretched titlebar: it's plausible the text is supposed to be 374 pixels (from the earlier coredump) wide, but it's stretched horizontally to fill the entire titlebar. I also saw a similarly stretched titlebar briefly when starting Chrome.

So that's not the right fix but hopefully that narrows it down a bit further... (I'll look into this more if I find time)

[kennylevinsen]

The PR I linked above has been merged to master and removes the use of a source box from sway_text_node entirely.

[marienz]

Ah, whoops, I'd missed the significance of that PR. Applying those two commits to 1.10.1 fixes the crash for me (without stretched titlebar text this time).

[itsTurnip]

I've met the same crash error while using Telegram after their 5.14.* update. This happens after some time of regular using app, and occasionally in some day it starts to crash sway session whenever I try to open it (I couldn't find the cause of this event).

I uploaded my sway debug log to gist, also there's WAYLAND_DEBUG.

[kennylevinsen]

Should be fixed by the sway release candidate.

[iNecas]

I've been hitting very similar issue in sway 1.11, wlroots 0.19:

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.

Happens randomly: Other logs in the log before the crash don't look relevant. I haven't found a reliable reproducer. This wlroots bug seems to be relevant https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3981. Unfortunately not running with debug symbols, so can't confirm yet. Will try running on the version with the patch + debug symbols in case I still hit this.