fix: panic on hyperland

[Decodetalkers]

relate: waycrate/wayshot#304

init ZXdgOutputInfo during wl_output callback, do not use oncecell set it later. Maybe dispatch is not finished

[Gigas002]

I'd like to wait a bit if more reports come, maybe it was a hyprland issue after all and we don't need a fix. Or you'd prefer to push this one just to be safe?

[Gigas002]

Hmm, I think it still happens sometimes, but pretty rarely. I'll test if this PR fixes the problem, though it's a bit hard to tell without proper repro scenario

[Gigas002]

The crash still happens rarely for me even when using this PR, and it's still happening seemingly random. I tried debugging it, but no luck, at least yet.

[Decodetalkers]

The crash still happens rarely for me even when using this PR, and it's still happening seemingly random. I tried debugging it, but no luck, at least yet.

What is the new panic information?

[Gigas002]

Can't confirm yet, happens too randomly. Will post again if I'll be able to reproduce with any logs at all.
At this point, what I can say for sure, is that crash occurs before selector's UI shows, so maybe it's about UI init? Didn't actually thought about it.

[id3v1669]

Can confirm the issue with -g flag and some observations that might help.
2 machines, both nixos, both hyprland on same flakes. On one of them wayshot works, on another crashes with log:

thread 'main' (20963) panicked at /build/wayshot-1.4.6-vendor/source-registry-0/libwaysip-0.6.0/src/state.rs:76:36:
should inited
stack backtrace:
   0:     0x55560e650f85 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h530ac34e196461be
   1:     0x55560e67f89a - core::fmt::write::hfebbe83a528033c1
   2:     0x55560e651a06 - std::io::default_write_fmt::h0ba17d3fe335279a
   3:     0x55560e64df06 - std::panicking::default_hook::{{closure}}::h19be2464c5c0a285
   4:     0x55560e64dda8 - std::panicking::default_hook::h613c80136145dcc7
   5:     0x55560e64e13b - std::panicking::panic_with_hook::hb09a36a2026ab877
   6:     0x55560e64dfb8 - std::panicking::panic_handler::{{closure}}::ha4299fe6dc67fbbc
   7:     0x55560e64d769 - std::sys::backtrace::__rust_end_short_backtrace::hafec91f98267cfd4
   8:     0x55560e64984d - __rustc[cba8e45071337d10]::rust_begin_unwind
   9:     0x55560e0d12cc - core::panicking::panic_fmt::h41b75fcbafe65d21
  10:     0x55560e0d0ed4 - core::option::expect_failed::hea06adb989b11a40
  11:     0x55560e3b458b - libwaysip::get_area_inner::hd26a37f758c118b0
  12:     0x55560e3b4be6 - libwaysip::WaySip::get::hb553a70113cd0774
  13:     0x55560e21c0e9 - wayshot::screenshot::capture_geometry::{{closure}}::h082691e88cb7dc76
  14:     0x55560e40549e - libwayshot::WayshotConnection::screenshot_region_capturer::h057f6b925f167fad
  15:     0x55560e21c62d - wayshot::screenshot::capture::ha0b3aebf35f3998c
  16:     0x55560e1fa9af - wayshot::main::h8f2e6bfd6b4745b9
  17:     0x55560e2131e6 - std::sys::backtrace::__rust_begin_short_backtrace::h57c6b7bd855ab89a
  18:     0x55560e1e4801 - std::rt::lang_start::{{closure}}::h9252227403a2d58d
  19:     0x55560e64c414 - std::rt::lang_start_internal::h68c86ce285fb0520
  20:     0x55560e1fb43d - main
  21:     0x7fad36c2b285 - __libc_start_call_main
  22:     0x7fad36c2b338 - __libc_start_main_alias_2
  23:     0x55560e0d12f5 - _start
  24:                0x0 - <unknown>

On both machines waysip itself with -d flag works fine.
Looks like the issue is that during initialization not all registry globals are fully received before processing.
Here is patch that solved the problem for me, please test it:

diff --git a/libwaysip/src/lib.rs b/libwaysip/src/lib.rs
index a6bea71..e4114a3 100644
--- a/libwaysip/src/lib.rs
+++ b/libwaysip/src/lib.rs
@@ -176,7 +176,7 @@ fn get_area_inner(
     // register this
 
     event_queue
-        .blocking_dispatch(&mut state)
+        .roundtrip(&mut state)
         .map_err(WaySipError::DispatchError)?; // then make a dispatch
 
     let xdg_output_manager = globals
@@ -192,7 +192,7 @@ fn get_area_inner(
     }
 
     event_queue
-        .blocking_dispatch(&mut state)
+        .roundtrip(&mut state)
         .map_err(WaySipError::DispatchError)?; // then make a dispatch
 
     // you will find you get the outputs, but if you do not

[Gigas002]

@id3v1669

Many thanks, will test this out! How do you manage to repro it though? No matter what I tried I couldn't force it to happen, only happens on rare random occasions for me

[id3v1669]

@id3v1669

How do you manage to repro it though?

wayshot just doesn't work at all with first pc and works without any issues on second, so no special steps to reproduce.

[Decodetalkers]

@id3v1669

How do you manage to repro it though?

wayshot just doesn't work at all with first pc and works without any issues on second, so no special steps to reproduce.

Can you pr that to me? I will merge that to this pr!

[Decodetalkers]

But I do not know why blocking_dispatch can cause that bug. I cannot understand . Blocking at that place should not cause any trouble

[Decodetalkers]

Can confirm the issue with -g flag and some observations that might help.
2 machines, both nixos, both hyprland on same flakes. On one of them wayshot works, on another crashes with log:

thread 'main' (20963) panicked at /build/wayshot-1.4.6-vendor/source-registry-0/libwaysip-0.6.0/src/state.rs:76:36:
should inited
stack backtrace:
   0:     0x55560e650f85 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h530ac34e196461be
   1:     0x55560e67f89a - core::fmt::write::hfebbe83a528033c1
   2:     0x55560e651a06 - std::io::default_write_fmt::h0ba17d3fe335279a
   3:     0x55560e64df06 - std::panicking::default_hook::{{closure}}::h19be2464c5c0a285
   4:     0x55560e64dda8 - std::panicking::default_hook::h613c80136145dcc7
   5:     0x55560e64e13b - std::panicking::panic_with_hook::hb09a36a2026ab877
   6:     0x55560e64dfb8 - std::panicking::panic_handler::{{closure}}::ha4299fe6dc67fbbc
   7:     0x55560e64d769 - std::sys::backtrace::__rust_end_short_backtrace::hafec91f98267cfd4
   8:     0x55560e64984d - __rustc[cba8e45071337d10]::rust_begin_unwind
   9:     0x55560e0d12cc - core::panicking::panic_fmt::h41b75fcbafe65d21
  10:     0x55560e0d0ed4 - core::option::expect_failed::hea06adb989b11a40
  11:     0x55560e3b458b - libwaysip::get_area_inner::hd26a37f758c118b0
  12:     0x55560e3b4be6 - libwaysip::WaySip::get::hb553a70113cd0774
  13:     0x55560e21c0e9 - wayshot::screenshot::capture_geometry::{{closure}}::h082691e88cb7dc76
  14:     0x55560e40549e - libwayshot::WayshotConnection::screenshot_region_capturer::h057f6b925f167fad
  15:     0x55560e21c62d - wayshot::screenshot::capture::ha0b3aebf35f3998c
  16:     0x55560e1fa9af - wayshot::main::h8f2e6bfd6b4745b9
  17:     0x55560e2131e6 - std::sys::backtrace::__rust_begin_short_backtrace::h57c6b7bd855ab89a
  18:     0x55560e1e4801 - std::rt::lang_start::{{closure}}::h9252227403a2d58d
  19:     0x55560e64c414 - std::rt::lang_start_internal::h68c86ce285fb0520
  20:     0x55560e1fb43d - main
  21:     0x7fad36c2b285 - __libc_start_call_main
  22:     0x7fad36c2b338 - __libc_start_main_alias_2
  23:     0x55560e0d12f5 - _start
  24:                0x0 - <unknown>

On both machines waysip itself with -d flag works fine.
Looks like the issue is that during initialization not all registry globals are fully received before processing.
Here is patch that solved the problem for me, please test it:

diff --git a/libwaysip/src/lib.rs b/libwaysip/src/lib.rs
index a6bea71..e4114a3 100644
--- a/libwaysip/src/lib.rs
+++ b/libwaysip/src/lib.rs
@@ -176,7 +176,7 @@ fn get_area_inner(
     // register this
 
     event_queue
-        .blocking_dispatch(&mut state)
+        .roundtrip(&mut state)
         .map_err(WaySipError::DispatchError)?; // then make a dispatch
 
     let xdg_output_manager = globals
@@ -192,7 +192,7 @@ fn get_area_inner(
     }
 
     event_queue
-        .blocking_dispatch(&mut state)
+        .roundtrip(&mut state)
         .map_err(WaySipError::DispatchError)?; // then make a dispatch
 
     // you will find you get the outputs, but if you do not

It seems not my pr, because I remove the OnceCell in this pr. It should never panic on +76. I still do not know if this pr is working

[id3v1669]

It seems not my pr

Yes, it's a patch to orig master branch as replacement to your pr as it fixes the issue(at least looks like it does).

Regarding why:
blocking_dispatch: Block waiting for events and dispatch them.
The problem is that there is no guarantee that server finished responding
to previous requests.
roundtrip will block until all pending requests are processed.
in waysip we send get_registry in fn get_area_inner and by blocking_dispatch it's not always
getting processed I guess.
This also explains why on my first pc it breaks - low freq cpu and it takes more time to process the requests and block happens before it's processed. While on my second pc it works - high freq cpu and it processes the requests faster and manages to go through get_registry before block.

[Decodetalkers]

It seems not my pr

Yes, it's a patch to orig master branch as replacement to your pr as it fixes the issue(at least looks like it does).

Regarding why: blocking_dispatch: Block waiting for events and dispatch them. The problem is that there is no guarantee that server finished responding to previous requests. roundtrip will block until all pending requests are processed. in waysip we send get_registry in fn get_area_inner and by blocking_dispatch it's not always getting processed I guess. This also explains why on my first pc it breaks - low freq cpu and it takes more time to process the requests and block happens before it's processed. While on my second pc it works - high freq cpu and it processes the requests faster and manages to go through get_registry before block.

Ok, I think you can send your pr to me, and I will merge it. I see, blocking_dispatch means that, seems I misunderstood it