Sway: [bug] sway consistently crashes if the song changes in mpv while the window is hidden in the scratchpad

[norcalli]

• Sway Version:

{
   "human_readable": "1.0-rc1-200-gd9de5b87 (Mar 25 2019, branch 'master')",
   "variant": "sway",
   "major": 1,
   "minor": 0,
   "patch": 0,
   "loaded_config_file_name": "\/home\/ashkan\/.config\/sway\/config"
 }

• Steps to reproduce:

Consistently, if I have mpv playing in a scratchpad and hidden and the song changes, it will crash sway.

• Stack Trace, if sway crashes:

(gdb) bt full 
#0  0x000056315a5452e8 in container_init_floating (con=0x56315b7c8000) at ../sway/sway/tree/container.c:655 
        ws = 0x0 
        ob = 0x7fd460a7d550 
        min_width = -517721104 
        max_width = 32766 
        min_height = 1542126080 
        max_height = -2008805100 
#1  0x000056315a5518bb in handle_request_configure (listener=0x56315b7c7050, data=0x7ffee12434f0) at ../sway/sway/desktop/xwayland.c:438 
        xwayland_view = 0x56315b7c6f00 
        ev = 0x7ffee12434f0 
        view = 0x56315b7c6f00 
        xsurface = 0x56315b7c6cb0 
#2  0x00007fd460a38ede in wlr_signal_emit_safe (signal=signal@entry=0x56315b7c6db8, data=data@entry=0x7ffee12434f0) at ../util/signal.c:29 
        pos = 0x56315b7c7050 
        l = 0x56315b7c7050 
        cursor = {link = {prev = 0x56315b7c7050, next = 0x7ffee1243480}, notify = 0x7fd460a38e50 <handle_noop>} 
        end = {link = {prev = 0x7ffee1243460, next = 0x56315b7c6db8}, notify = 0x7fd460a38e50 <handle_noop>} 
#3  0x00007fd4609f7a49 in xwm_handle_configure_request (ev=0x56315b82b830, xwm=0x56315b753790) at ../xwayland/xwm.c:878 
        surface = 0x56315b7c6cb0 
        mask = <optimized out> 
        geo_mask = 15 
        wlr_event = {surface = 0x56315b7c6cb0, x = 1407, y = 587, width = 960, height = 480} 
        count = 1 
        event = 0x56315b82b830 
        xwm = 0x56315b753790 
#4  0x00007fd4609f7a49 in x11_event_handler (fd=<optimized out>, mask=<optimized out>, data=0x56315b753790) at ../xwayland/xwm.c:1323 
        count = 1 
        event = 0x56315b82b830 
        xwm = 0x56315b753790 
#5  0x00007fd460a7c7f2 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0 
#6  0x00007fd460a7b39c in wl_display_run () at /usr/lib/libwayland-server.so.0 
#7  0x000056315a50e561 in server_run (server=0x56315a572e40 <server>) at ../sway/sway/server.c:216 
#8  0x000056315a50da78 in main (argc=1, argv=0x7ffee12438b8) at ../sway/sway/main.c:398 
        verbose = 0 
        debug = 0 
        validate = 0 
        allow_unsupported_gpu = 0 
        long_options = 
            {{name = 0x56315a558ed0 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x56315a558ed5 "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x56315a558edc "validate", has_arg = 0, flag = 0x0, val = 67}, {name = 0x56315a558ee5 "debug", has_arg = 0, flag = 0x0, val = 100}, {name = 0x56315a558eeb "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x56315a558ef3 "verbose", has_arg = 0, flag = 0x0, val = 86}, {name = 0x56315a558efb "get-socketpath", has_arg = 0, flag = 0x0, val = 112}, {name = 0x56315a558f0a "unsupported-gpu", has_arg = 0, flag = 0x0, val = 117}, {name = 0x56315a558f1a "my-next-gpu-wont-be-nvidia", has_arg = 0, flag = 0x0, val = 117}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} 
        config_path = 0x0 
        usage = 0x56315a558998 "Usage: sway [options] [command]\n\n  -h, --help", ' ' <repeats 13 times>, "Show help message and quit.\n  -c, --config <config>  Specify a config file.\n  -C, --validate         Check the validity of the config file, th"... 
        c = -1 
(gdb)

[schauveau]

I confirm the bug. Obviously, X11 windows in the scratchpad have a NULL workspace (ws = 0x0) thus causing the crash when MPV attempts to reconfigure its geometry.
Though, the issue seems limited to xwayland. No crash for me when using the wayland backend of MPV.

mpv --vo=gpu --gpu-context=wayland ...

[schauveau]

I found another way to trigger that crash. I did not check the debug output but this is likely the same issue: Send a fullscreen toggle command to a scratchpad window. However, that one is not limited to X11 windows as illustrated by:

/usr/lib/weston/weston-simple-egl &
sleep 1
swaymsg "[title=simple-egl] move scratchpad"
#  bye bye Sway ....
swaymsg "[title=simple-egl] fullscreen toggle"

[RedSoxFan]

I found another way to trigger that crash

That actually is a separate issue. The original one is when a xwayland client sends a configure request while the view is in the scratchpad. That one is an issue attempting to fullscreen a container that is in the scratchpad and does not have a workspace. The crashes are in two completely different functions:

#0  container_set_fullscreen (con=0x5562e4c72610, mode=FULLSCREEN_WORKSPACE)
    at ../sway/tree/container.c:1025
1025            if (con->workspace->fullscreen) {
(gdb) bt full
#0  0x00005562e30498f0 in container_set_fullscreen
    (con=0x5562e4c72610, mode=FULLSCREEN_WORKSPACE) at ../sway/tree/container.c:1025
#1  0x00005562e3033669 in cmd_fullscreen (argc=0, argv=0x5562e4bf9388)
    at ../sway/commands/fullscreen.c:58
        error = 0x0
        node = 0x5562e4c72610
        container = 0x5562e4c72610
        workspace = 0x0
        is_fullscreen = false
        global = false
        enable = true
        mode = FULLSCREEN_WORKSPACE

[schauveau]

Well... not exactly identical but isn't the root cause the same? Segfault on con->workspace->fullscreen because con->workspace is null. Right? If so, the question becomes: are there any other cases where a null workspace could cause problem? My point is that there are two ways to solve the problem:

• First, by fixing all places where workspace could be null.
• Second, by creating a 'dummy' workspace for the scratchpad.

IMHO, the second approach would be more robust.

[norcalli]

I have a new backtrace of the same problem: I woke up this morning after leaving my computer awake (sleep is disabled) and found that sway had crashed. It seems as if Gmail received an email while it was floating in scratchpad and triggered a title update, which crashed due to workspace being "0x0":

Backtrace:

(gdb) bt full
#0  0x0000558ca6ba4da9 in arrange_workspace (workspace=0x0) at ../sway/sway/tree/arrange.c:183
        output = 0x558ca6bd4370 <command_handlers+48>
        area = 0x7fffc7abb650
        first_arrange = 166
        prev_x = 6.9533091162607477e-310
        prev_y = 4.6473089931962002e-310
        diff_x = 0
        diff_y = 6.9491310296008822e-310
#1  0x0000558ca6b909be in cmd_floating (argc=1, argv=0x558ca981b848) at ../sway/sway/commands/floating.c:48
        error = 0x0
        container = 0x558ca99189f0
        workspace = 0x0
        wants_floating = true
#2  0x0000558ca6b628a9 in execute_command (_exec=0x558ca97099f0 "floating enable, move scratchpad, border pixel 5", seat=0x558ca9307630, con=0x558ca99189f0) at ../sway/sway/commands.c:287
        node = 0x558ca99189f0
        res = 0x558ca9916240
        argc = 2
        argv = 0x558ca981b840
        handler = 0x558ca6bd4370 <command_handlers+48>
        res_list = 0x558ca9528d00
        exec = 0x558ca99ceac0 "floating enable"
        head = 0x0
        cmdlist = 0x558ca99cead0 " move scratchpad, border pixel 5"
        cmd = 0x558ca99ceac0 "floating enable"
        views = 0x0
        __PRETTY_FUNCTION__ = "execute_command"
#3  0x0000558ca6bacf5d in view_execute_criteria (view=0x558ca9904c90) at ../sway/sway/tree/view.c:448
        criteria = 0x558ca9673bd0
        res_list = 0x3e
        i = 0
        criterias = 0x558ca9628350
#4  0x0000558ca6bb3bb2 in handle_set_title (listener=0x558ca9904e28, data=0x558ca9916240) at ../sway/sway/desktop/xwayland.c:520
        xwayland_view = 0x558ca9904c90
        view = 0x558ca9904c90
        xsurface = 0x558ca9916240
#5  0x00007fec1754eede in wlr_signal_emit_safe (signal=signal@entry=0x558ca99163c8, data=data@entry=0x558ca9916240) at ../util/signal.c:29
        pos = 0x558ca9904e28
        l = 0x558ca9904e28
        cursor = {link = {prev = 0x558ca9904e28, next = 0x7fffc7abb810}, notify = 0x7fec1754ee50 <handle_noop>}
        end = {link = {prev = 0x7fffc7abb7f0, next = 0x558ca99163c8}, notify = 0x7fec1754ee50 <handle_noop>}
#6  0x00007fec1750cd8f in read_surface_title (xwm=0x558ca99777a0, reply=0x558ca98603d0, xsurface=0x558ca9916240) at ../xwayland/xwm.c:442
        is_utf8 = <optimized out>
        len = <optimized out>
        title = 0x558ca98603f0 "Inbox (2) -  - Gmail - Firefox Nightly"
        cookie = <optimized out>
        reply = 0x558ca98603d0
#7  0x00007fec1750cd8f in read_surface_property (xwm=xwm@entry=0x558ca9879f90, xsurface=0x558ca9916240, property=<optimized out>) at ../xwayland/xwm.c:701
        cookie = <optimized out>
        reply = 0x558ca98603d0
#8  0x00007fec1750d932 in xwm_handle_property_notify (ev=0x558ca954fd20, ev=0x558ca954fd20, xwm=0x558ca9879f90) at ../xwayland/xwm.c:973
        xsurface = <optimized out>
        count = 1
        event = 0x558ca954fd20
        xwm = 0x558ca9879f90
#9  0x00007fec1750d932 in x11_event_handler (fd=<optimized out>, mask=<optimized out>, data=0x558ca9879f90) at ../xwayland/xwm.c:1340
        count = 1
        event = 0x558ca954fd20
        xwm = 0x558ca9879f90
#10 0x00007fec175927f2 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#11 0x00007fec1759139c in wl_display_run () at /usr/lib/libwayland-server.so.0
#12 0x0000558ca6b70561 in server_run (server=0x558ca6bd4e40 <server>) at ../sway/sway/server.c:216
#13 0x0000558ca6b6fa78 in main (argc=1, argv=0x7fffc7abbcc8) at ../sway/sway/main.c:398
        verbose = 0
        debug = 0
        validate = 0
        allow_unsupported_gpu = 0
        long_options =
            {{name = 0x558ca6bbaed0 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x558ca6bbaed5 "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x558ca6bbaedc "validate", has_arg = 0, flag = 0x0, val = 67}, {name = 0x558ca6bbaee5 "debug", has_arg = 0, flag = 0x0, val = 100}, {name = 0x558ca6bbaeeb "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x558ca6bbaef3 "verbose", has_arg = 0, flag = 0x0, val = 86}, {name = 0x558ca6bbaefb "get-socketpath", has_arg = 0, flag = 0x0, val = 112}, {name = 0x558ca6bbaf0a "unsupported-gpu", has_arg = 0, flag = 0x0, val = 117}, {name = 0x558ca6bbaf1a "my-next-gpu-wont-be-nvidia", has_arg = 0, flag = 0x0, val = 117}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
        config_path = 0x0
        usage = 0x558ca6bba998 "Usage: sway [options] [command]\n\n  -h, --help", ' ' <repeats 13 times>, "Show help message and quit.\n  -c, --config <config>  Specify a config file.\n  -C, --validate         Check the validity of the config file, th"...
        c = -1
(gdb)

Again, this seems to be related to workspace being null.

[RedSoxFan]

My point is that there are two ways to solve the problem:

• First, by fixing all places where workspace could be null.
• Second, by creating a 'dummy' workspace for the scratchpad.

iirc we actually did use a dummy workspace originally, but had the same problem with the workspace's output being NULL. This did predate the noop backend for wlroots though. Now that the noop backend exists, it might be worth considering migrating the scratchpad over to a workspace that is locked to the noop output or a separate noop output exclusively for the scratchpad

[norcalli]

@RedSoxFan Do you think there a quick patch I could introduce to make sway usable in the meantime for myself (before I start trying to figure it out myself), because this problem seems more complicated than I originally guessed.

[schauveau]

@norcalli I am not 100% sure that this will work but I propose the following changes.
For your gmail crash, you could edit line 48 of ./sway/commands/floating.c as follow:

        arrange_workspace(container->workspace);

to

        if (container->workspace)  
            arrange_workspace(container->workspace);

And for the mpv crash you could try to edit the beginning of container_init_floating() around line 656 of sway/tree/container.c as follow:

    if (!ob) {
                con->x = 0;
                con->y = 0;
                con->width = 0;
                con->height = 0;
                return
    }

to

      if (!ob || !ws) {
                con->x = 0;
                con->y = 0;
                con->width = 0;
                con->height = 0;   
               return
    }

I am less sure about about that second change since I do not know how the container will react with x=y=weight=height=0

[RedSoxFan]

@norcalli For the gmail crash, the snippet that schauveau provided should work. @schauveau Do you mind submitting a PR with that change (note that the code style in use for sway requires the braces be used)?

As for the mpv crash, I'll submit a PR to fix that shortly. Ideally, the size request would be honored (restricted by min and max size) and just skip centering it

[norcalli]

@RedSoxFan I went ahead and did it for that one line, but it seems like you're getting all the other instances. I'll test them out and check for any other crashes.

[RedSoxFan]

Reopening until the other two crashes are fixed in master... So much for editing that "Fixes" line to point to just the comment so GitHub wouldn't close the whole issue...

[norcalli]

I've been using the patches and have absolutely 0 crashes. Thank you very much @RedSoxFan and @schauveau ! I'll keep stress testing scratchpads since I've recently made them a huge part of my workflow.