Crash on starting program

[J0nnyMak0]

With latest Sway and wlroots sources, I'm getting intermittent crashes on starting certain programs. One such stack trace attached when starting Chrome.

sway version 1.10-dev-e39b0b81 (Jan 27 2024, branch 'master')

gdb.txt

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {206158430256}}
        ret = <optimized out>
#1  0x00007baad2d5f8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007baad2d0f668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x00007baad2cf74b8 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {224, 103436423027904, 135973611943880, 135973613247168, 0, 135973621848960, 23, 135973621849032, 135973611944745, 5, 140721699074144, 0, 135973613031872, 18446744073709551064, 11, 135973621848960}}, sa_flags = -757669037, sa_restorer = 0x7baad2ea8070 <_IO_file_jumps>}
#4  0x00007baad2cf73dc in __assert_fail_base (fmt=0x7baad2e70ae8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7baad36ddbc8 "box->x >= 0 && box->y >= 0 && box->x + box->width <= options->texture->width && box->y + box->height <= options->texture->height", file=file@entry=0x7baad36ddb80 "render/pass.c", line=line@entry=23, function=function@entry=0x7baad36ddcb0 <__PRETTY_FUNCTION__.1> "wlr_render_pass_add_texture") at assert.c:92
        str = 0x5e132b405bf0 "0\221\246+\023^"
        total = 4096
#5  0x00007baad2d07d26 in __assert_fail (assertion=0x7baad36ddbc8 "box->x >= 0 && box->y >= 0 && box->x + box->width <= options->texture->width && box->y + box->height <= options->texture->height", file=0x7baad36ddb80 "render/pass.c", line=23, function=0x7baad36ddcb0 <__PRETTY_FUNCTION__.1> "wlr_render_pass_add_texture") at assert.c:101
#6  0x00007baad36151d4 in wlr_render_pass_add_texture (render_pass=0x5e132b608d60, options=0x7ffc52e2b290) at ../subprojects/wlroots/render/pass.c:23
        box = 0x7ffc52e2b298
        __PRETTY_FUNCTION__ = "wlr_render_pass_add_texture"
#7  0x00007baad3662126 in scene_entry_render (entry=0x5e132ba8b9e8, data=0x7ffc52e2b490) at ../subprojects/wlroots/types/scene/wlr_scene.c:1203
        texture = 0x5e132ba5c570
        scene_rect = 0x5e132ba75200
        scene_buffer = 0x5e132ba532c0
        transform = WL_OUTPUT_TRANSFORM_NORMAL
        sample_event = {output = 0x7ffc52e2b280, direct_scanout = 34}
        node = 0x5e132ba532c0
        render_region = {extents = {x1 = 6, y1 = 5, x2 = 3834, y2 = 36}, data = 0x0}
        dst_box = {x = 8, y = 6, width = 3825, height = 29}
        opaque = {extents = {x1 = 6, y1 = 5, x2 = 3834, y2 = 36}, data = 0x0}
        __PRETTY_FUNCTION__ = "scene_entry_render"
#8  0x00007baad3663e04 in wlr_scene_output_build_state (scene_output=0x5e132b62b620, state=0x7ffc52e2b510, options=0x7ffc52e2b340) at ../subprojects/wlroots/types/scene/wlr_scene.c:1875
        entry = 0x5e132ba8b9e8
        i = 5
        default_options = {timer = 0x0}
        timer = 0x0
        start_time = {tv_sec = 9980523536, tv_nsec = 103436420789200}
        output = 0x5e132b63d1c0
        debug_damage = WLR_SCENE_DEBUG_DAMAGE_NONE
        render_data = {transform = WL_OUTPUT_TRANSFORM_NORMAL, scale = 1.5, logical = {x = 0, y = 0, width = 2560, height = 1440}, trans_width = 3840, trans_height = 2160, output = 0x5e132b62b620, render_pass = 0x5e132b608d60, damage = {extents = {x1 = 6, y1 = 5, x2 = 3840, y2 = 523}, data = 0x5e132b604c50}}
        list_con = {box = {x = 0, y = 0, width = 2560, height = 1440}, render_list = 0x5e132b62b850, calculate_visibility = true}

[vyivel]

Can you try with latest wlroots master? This should be fixed with https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4527.

[J0nnyMak0]

Can you try with latest wlroots master? This should be fixed with https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4527.

I don't think that is it. I'm already on 4688a37

[J0nnyMak0]

FWIW after Chrome crashes the first time, subsequent crashes are consistently reproducible. The crash happens when clicking on the "Restore" button in the "Restore pages?" dialog:

[Nefsen402]

This might be a heap corruption. Please try running with asan to narrow it down.

[J0nnyMak0]

Asan log attached.
sway.log

[Nefsen402]

That isn't a asan log but at the end we have:

00:00:28.430 [ERROR] [sway/sway_text_node.c:106] cairo_image_surface_create failed: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
00:00:28.431 [ERROR] [sway/sway_text_node.c:106] cairo_image_surface_create failed: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
00:00:28.431 [ERROR] [sway/sway_text_node.c:106] cairo_image_surface_create failed: invalid value (typically too big) for the size of the input (surface, pattern, etc.)

So somehow sway_text_node calculated a bad value and passed it around until it finally asserted on something.

[Nefsen402]

I'm gonna have a bet and say those values are a negative number? Negative size configure? Attaching a debugger to the coredump and inspecting the width and height variables in the render_backing_buffer function would be very helpful.

[Nefsen402]

diff --git a/sway/sway_text_node.c b/sway/sway_text_node.c
index b9a77d94..a1288b83 100644
--- a/sway/sway_text_node.c
+++ b/sway/sway_text_node.c
@@ -58,11 +58,14 @@ struct text_buffer {
 };
 
 static int get_text_width(struct sway_text_node *props) {
+       int size;
        if (props->max_width) {
-               return MIN(props->max_width, props->width);
+               size = MIN(props->max_width, props->width);
+       } else {
+               size = props->width;
        }
 
-       return props->width;
+       return MAX(size, 0);
 }
 
 static void update_source_box(struct text_buffer *buffer) {

This patch may fix the problem.

[J0nnyMak0]

Yep, that patch fixed the crash! Thanks!

[J0nnyMak0]

I can attach the debugger and verify the values if you'd like to confirm.

[Nefsen402]

That's fine, the patch is enough to confirm it was a negative number floating around.

[J0nnyMak0]

Having said that, I'm confused as to why asan log wasn't generated. I'm setting up the build with:

 meson setup build -Db_sanitize=address,undefined

And running:

 ASAN_OPTIONS=abort_on_error=1:disable_coredump=0:unmap_shadow_on_exit=1 sway -d 2> sway.log

Unless, I got even more confused and attached the wrong log file...

[Nefsen402]

I don't think there are any memory integrity issues here. Asan wouldn't catch anything in this case. It might have been enabled, it just didn't play a role.