Sway 1.2 crashes after copy/paste with wl-copy in neovim

[arolle]

• sway version 1.2 (Aug 29 2019, Arch Linux)`
• nvim --version v0.3.8

Explanation of steps taken to reproduce the issue.

$ nvim -u NONE -V10nvimdebug.log \
  -c "set clipboard=unnamed,unnamedplus" \
  -c "silent normal ii" -c "silent normal yypp"

Then neovim is not responsive and sway (with default config) crashes when opening
new terminals. Earlier this had worked.

line 0: sourcing "/usr/share/nvim/runtime/autoload/provider/clipboard.vim"
finished sourcing /usr/share/nvim/runtime/autoload/provider/clipboard.vim
continuing in command line
[...]
clipboard: error invoking wl-copy: wl_display_dispatch: Broken pipe 
clipboard: error invoking wl-copy: wl_display_dispatch: Broken pipe 
Writing ShaDa file [...]

Sway stack trace and debug log

                #0  0x00007f270a04eb58 wlr_seat_keyboard_enter (libwlroots.so.3)
                #1  0x0000559ccb609368 n/a (sway)
                #2  0x0000559ccb5ebee3 n/a (sway)
                #3  0x0000559ccb61530c n/a (sway)
                #4  0x00007f270a075cfe n/a (libwlroots.so.3)
                #5  0x00007f270a05a4da n/a (libwlroots.so.3)
                #6  0x00007f270a0710ba n/a (libwlroots.so.3)
                #7  0x00007f270a0713b8 n/a (libwlroots.so.3)
                #8  0x00007f27095246d0 ffi_call_unix64 (libffi.so.6)
                #9  0x00007f27095240a0 ffi_call (libffi.so.6)
                #10 0x00007f270a0bc82f n/a (libwayland-server.so.0)
                #11 0x00007f270a0b9193 n/a (libwayland-server.so.0)
                #12 0x00007f270a0ba7f2 wl_event_loop_dispatch (libwayland-server.so.0)
                #13 0x00007f270a0b939c wl_display_run (libwayland-server.so.0)
                #14 0x0000559ccb5de592 n/a (sway)
                #15 0x00007f270a6b8ee3 __libc_start_main (libc.so.6)
                #16 0x0000559ccb5de8be n/a (sway)

[ghost]

I think it's worth noting that this happens with master version of wl-clipboard. release version does not work at all

P.S it only happens when pasting from primary clipboard

[emersion]

Can you compile sway with debugging symbols?

[emersion]

Also please use coredumpctl to get the stack trace. You can do so by running coredumpctl gdb and then bt full.

[chebykinn]

This is the same bug I was talking about in #4502, I have the same neovim clipboard option.

[vilhalmer]

I just ran into this as well and reproduced with a minimal config:

bindsym Mod4+Return exec termite

All you have to do is start sway, run a terminal, run wl-paste -p, and change focus.

Backtrace with symbols: https://paste.sr.ht/~vilhalmer/09c9f6f00f4e9bc5a6c54a8ee6feb69c725e3904

[vilhalmer]

Ah, here's a better one with wlroots symbols too. https://paste.sr.ht/~vilhalmer/079ff30ae36211ddd525f7767c77f1c5b99a4b0a

[emersion]

ASan trace:

==24081==ERROR: AddressSanitizer: heap-use-after-free on address 0x613000023ad0 at pc 0x55e08faf1627 bp 0x7ffd4da86f10 sp 0x7ffd4da86f00
READ of size 8 at 0x613000023ad0 thread T0
    #0 0x55e08faf1626 in seat_set_focus_layer ../sway/input/seat.c:1098
    #1 0x55e08faef945 in seat_set_focus ../sway/input/seat.c:918
    #2 0x55e08fbd63fd in workspace_switch ../sway/tree/workspace.c:482
    #3 0x55e08fb71145 in cmd_workspace ../sway/commands/workspace.c:232
    #4 0x55e08fa444d5 in execute_command ../sway/commands.c:281
    #5 0x55e08fb31165 in seat_execute_command ../sway/commands/bind.c:624
    #6 0x55e08fadbdc1 in handle_keyboard_key ../sway/input/keyboard.c:422
    #7 0x7f0370e946c4 in wlr_signal_emit_safe ../subprojects/wlroots/util/signal.c:29
    #8 0x7f0370e252af in wlr_keyboard_notify_key ../subprojects/wlroots/types/wlr_keyboard.c:94
    #9 0x7f0370d4a246 in keyboard_handle_key ../subprojects/wlroots/backend/wayland/wl_seat.c:256
    #10 0x7f036e58d6cf in ffi_call_unix64 (/lib64/libffi.so.6+0x66cf)
    #11 0x7f036e58d09f in ffi_call (/lib64/libffi.so.6+0x609f)
    #12 0x7f036f4fbf8e  (/lib64/libwayland-client.so.0+0x8f8e)
    #13 0x7f036f4f86b9  (/lib64/libwayland-client.so.0+0x56b9)
    #14 0x7f036f4f9bfb in wl_display_dispatch_queue_pending (/lib64/libwayland-client.so.0+0x6bfb)
    #15 0x7f0370d3de78 in dispatch_events ../subprojects/wlroots/backend/wayland/backend.c:37
    #16 0x7f037039a7f1 in wl_event_loop_dispatch (/lib64/libwayland-server.so.0+0xa7f1)
    #17 0x7f037039939b in wl_display_run (/lib64/libwayland-server.so.0+0x939b)
    #18 0x55e08fa7ecd4 in server_run ../sway/server.c:202
    #19 0x55e08fa7b5c1 in main ../sway/main.c:400
    #20 0x7f036f80eee2 in __libc_start_main (/lib64/libc.so.6+0x26ee2)
    #21 0x55e08fa4217d in _start (/home/simon/src/sway/build/sway/sway+0x2c517d)

0x613000023ad0 is located 16 bytes inside of 344-byte region [0x613000023ac0,0x613000023c18)
freed by thread T0 here:
    #0 0x7f037143d6c0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:122
    #1 0x7f0370e296c6 in layer_surface_destroy ../subprojects/wlroots/types/wlr_layer_shell_v1.c:216
    #2 0x7f0370e2c74b in client_handle_destroy ../subprojects/wlroots/types/wlr_layer_shell_v1.c:432
    #3 0x7f0370398d6e  (/lib64/libwayland-server.so.0+0x8d6e)

previously allocated by thread T0 here:
    #0 0x7f037143dce8 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7f0370e2bafe in layer_shell_handle_get_layer_surface ../subprojects/wlroots/types/wlr_layer_shell_v1.c:361
    #2 0x7f036e58d6cf in ffi_call_unix64 (/lib64/libffi.so.6+0x66cf)

SUMMARY: AddressSanitizer: heap-use-after-free ../sway/input/seat.c:1098 in seat_set_focus_layer
Shadow bytes around the buggy address:
  0x0c267fffc700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c267fffc710: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c267fffc720: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c267fffc730: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c267fffc740: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
=>0x0c267fffc750: fa fa fa fa fa fa fa fa fd fd[fd]fd fd fd fd fd
  0x0c267fffc760: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c267fffc770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c267fffc780: fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c267fffc790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c267fffc7a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==24081==ABORTING

[emersion]

Can you try #4525?

I have no clue why wl-clipboard creates a layer surface when using the data-control protocol.

[vilhalmer]

I have no clue why wl-clipboard creates a layer surface when using the data-control protocol.

This might be a leftover from pre-data-control days. I didn't know it was still doing it.