Supreeeme / xwayland-satellite

Xwayland outside your Wayland
Mozilla Public License 2.0
93 stars 4 forks source link

Random crash on IntelliJ paste #27

Closed YannikSc closed 2 days ago

YannikSc commented 3 weeks ago

I'm not sure how exactly it happened and I cannot reproduce it, but I got some logging and it might help to improve this project.

I will continue to monitor, log and try to find a pattern but for now here is a snippet from my log:

2024-06-17T07:10:36.530Z WARN  xwayland_satellite::xstate::selection > unexpected format: 0 (atom: UTF8_STRING, type: "None", property: Atom { res_id: 488 }) - copies as this type will fail!
 2024-06-17T07:17:27.528Z WARN  xwayland_satellite::xstate            > unrecognized message: Atom { res_id: 252 }
 2024-06-17T07:17:27.529Z WARN  xwayland_satellite::server::event     > unhandled xdgtoplevel event: ConfigureBounds { width: 2540, height: 1392 }
 2024-06-17T07:17:27.529Z WARN  xwayland_satellite::server::event     > unhandled xdgtoplevel event: WmCapabilities { capabilities: [3, 0, 0, 0] }
 2024-06-17T08:10:52.551Z WARN  xwayland_satellite::xstate::selection > unexpected format: 0 (atom: UTF8_STRING, type: "None", property: Atom { res_id: 488 }) - copies as this type will fail!
thread 'main' panicked at src/xstate/selection.rs:224:53:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
 2024-06-17T08:11:06.484Z INFO  xwayland_process                      > An output named 'DP-1' already existsAn output named 'DP-3' already existsAn output named 'DP-1' already existsAn output named 'DP-3' already exists(EE) failed to read Wayland events: Connection reset by peer
*end of log*
galister commented 2 weeks ago

happened to me after the clipboard sync commit. it happens when the clipboard is empty. because of the clipboard sync feature, it shouldn't be empty, but what i noticed is that it'll just eat whatever it on clipboard and both the x and wl clipboards are set to empty for no apparent reason (not even trying to paste into xwayland at this point yet)

galister commented 2 weeks ago

I'm not sure why, but I just can't get clipboard to work at all, even with the old "pipe wl-paste to xclip" method.

it just seems to wipe the wayland clipboard and then crash due to it being empty.

I ended up reverting the clipboard sync commit for myself to be able to use the clipboard again.

Supreeeme commented 1 week ago

@galister I can't seem to reproduce this, how do you get an empty clipboard? I also can't reproduce wl-paste | xclip exploding.

galister commented 1 week ago

@Supreeeme for me, xwayland-satellite just emptied it whenever i focused an xwayland window. my xwayland clipboard was essentially non-existent, i couldn't paste into any xorg window from wayland

if i had a wayland thing on my clipboard, then focused an xorg window, then went and tried to paste the wayland clipboard into a wayland window, it was gone as well

Supreeeme commented 1 week ago

Could you post a log with RUST_LOG=debug?

galister commented 1 week ago
 2024-06-27T02:25:30.095Z DEBUG xwayland_satellite::xstate::selection > Got selection request for target text/plain;charset=utf-8
 2024-06-27T02:25:30.095Z DEBUG xwayland_satellite::xstate::selection > refusing selection requst because given atom could not be found (Atom { res_id: 335 })
 2024-06-27T02:25:30.095Z DEBUG xwayland_satellite::xstate            > new window: CreateNotifyEvent { response_type: 16, pad: 1, sequence: 649, parent: Window { res_id: 954 }, window: Window { res_id: 6296623 }, x: -100, y: -100, width: 10, height: 10, border_width: 0, override_redirect: true, pad: 1 }
 2024-06-27T02:25:30.095Z DEBUG xwayland_satellite::xstate::selection > Got selection request for target text/plain;charset=utf-8
 2024-06-27T02:25:30.095Z DEBUG xwayland_satellite::xstate::selection > refusing selection requst because given atom could not be found (Atom { res_id: 335 })
 2024-06-27T02:25:30.095Z DEBUG xwayland_satellite::xstate::selection > Got selection request for target UTF8_STRING
thread 'main' panicked at src/xstate/selection.rs:224:53:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0:     0x5567237983d2 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hffecb437d922f988
   1:     0x5567237bf77c - core::fmt::write::hd9a8d7d029f9ea1a
   2:     0x556723795a2f - std::io::Write::write_fmt::h0e1226b2b8d973fe
   3:     0x5567237981a4 - std::sys_common::backtrace::print::he907f6ad7eee41cb
   4:     0x556723799aeb - std::panicking::default_hook::{{closure}}::h3926193b61c9ca9b
   5:     0x556723799843 - std::panicking::default_hook::h25ba2457dea68e65
   6:     0x556723799f8d - std::panicking::rust_panic_with_hook::h0ad14d90dcf5224f
   7:     0x556723799e29 - std::panicking::begin_panic_handler::{{closure}}::h4a1838a06f542647
   8:     0x5567237988a6 - std::sys_common::backtrace::__rust_end_short_backtrace::h77cc4dc3567ca904
   9:     0x556723799b94 - rust_begin_unwind
  10:     0x55672355ffc5 - core::panicking::panic_fmt::h940d4fd01a4b4fd1
  11:     0x556723560083 - core::panicking::panic::h8ddd58dc57c2dc00
  12:     0x55672355ff66 - core::option::unwrap_failed::hf59153bb1e2fc334
  13:     0x5567235eeb28 - xwayland_satellite::xstate::XState::handle_events::hf747725c168f7c8c
  14:     0x5567235ca42e - xwayland_satellite::main::hbf1418ad58f5862a
  15:     0x55672359c883 - std::sys_common::backtrace::__rust_begin_short_backtrace::had350edffe1f448a
  16:     0x5567235b06b9 - std::rt::lang_start::{{closure}}::h18633ddb227da39d
  17:     0x5567237916d3 - std::rt::lang_start_internal::h103c42a9c4e95084
  18:     0x5567235caa35 - main
  19:     0x7fea70b462f0 - <unknown>
  20:     0x7fea70b463a9 - __libc_start_main
  21:     0x556723560625 - _start
  22:                0x0 - <unknown>
Supreeeme commented 3 days ago

Okay, just pushed a commit that should at least avoid the crash, let me know if it's still reproducible. @galister does the clipboard still get erased?

galister commented 3 days ago

As of d32eae1 it no longer crashes, but it also doesn't sync and even the manual wl-copy | xclip -selection clipboard method doesn't do anything. I can copy text between 2 wayland apps and I can copy text between 2 xorg apps, but not between wayland and xorg.

Supreeeme commented 2 days ago

Hm, I can't reproduce at all. Seeing as the original crash is fixed I'm going to close this, but can you create a separate bug with more info? Namely system information, and a log with RUST_LOG="debug,xwayland_satellite::xstate::selection=trace".