starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

Crash on startup #3

New Issue
Closed
opened 2026-01-05 14:47:35 +01:00 by adam · 6 comments
adam commented 2026-01-05 14:47:35 +01:00
Owner
Copy Link

Originally created by @naoey on GitHub (Aug 13, 2021).

Originally assigned to: @LGUG2Z on GitHub.

Hello!

Just wanted to say thank you for building this as I've recently switched over to working on Windows and have sorely missed having a WM like this coming from using yabai on macOS. I've gone through the setup as described in the readme but haven't been able to get komorebi up and running yet.

I attempted to get it started as described in the instructions:

PS C:\Users\naoey> komorebic.exe start
Start-Process komorebi -WindowStyle hidden

However nothing happens after this and on running komorebi.exe state I see this output:

PS C:\Users\naoey> komorebic.exe state
Error: No connection could be made because the target machine actively refused it. (os error 10061)

Location:
    /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\result.rs:1675:27

Attempting to run komorebi.exe directly there appears to be an exception on startup causing the process to terminate:

$env:RUST_BACKTRACE = 'full'; komorebi.exe
Aug 13 11:28:17.651  INFO init: komorebi::window_manager: initialising
The application panicked (crashed).
Message:  removal index (is 1) should be < len (is 0)
Location: library\alloc\src\vec\mod.rs:1385

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 9 frames hidden ⋮
  10: alloc::vec::{{impl}}::remove::assert_failed<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\alloc\src\vec\mod.rs:1385
  11: komorebi::workspace::Workspace::remove_window::h4846824783ba2b6e
      at <unknown source file>:<unknown line>
  12: komorebi::windows_api::WindowsApi::load_workspace_information::h5f9f2afc54eb18e1
      at <unknown source file>:<unknown line>
  13: komorebi::window_manager::WindowManager::init::h5dc04cec6e26d635
      at <unknown source file>:<unknown line>
  14: <crossbeam_channel::flavors::array::Channel<T> as core::ops::drop::Drop>::drop::h0095431d3770ac30
      at <unknown source file>:<unknown line>
  15: std::sys_common::backtrace::__rust_begin_short_backtrace::h53b0089f6784328f
      at <unknown source file>:<unknown line>
  16: std::rt::lang_start::{{closure}}::h945d8ad2027e9b68
      at <unknown source file>:<unknown line>
  17: core::ops::function::impls::{{impl}}::call_once<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\ops\function.rs:280
  18: std::panicking::try::do_call<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:401
  19: std::panicking::try<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:365
  20: std::panic::catch_unwind<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panic.rs:434
  21: std::rt::lang_start_internal<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\rt.rs:34
  22: main<unknown>
      at <unknown source file>:<unknown line>
  23: invoke_main<unknown>
      at d:\a01\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  24: __scrt_common_main_seh<unknown>
      at d:\a01\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  25: BaseThreadInitThunk<unknown>
      at <unknown source file>:<unknown line>
  26: RtlUserThreadStart<unknown>
      at <unknown source file>:<unknown line>

This is running on the current latest master @ c15f1e1.

Originally created by @naoey on GitHub (Aug 13, 2021). Originally assigned to: @LGUG2Z on GitHub. Hello! Just wanted to say thank you for building this as I've recently switched over to working on Windows and have sorely missed having a WM like this coming from using yabai on macOS. I've gone through the setup as described in the readme but haven't been able to get komorebi up and running yet. I attempted to get it started as described in the instructions: ``` PS C:\Users\naoey> komorebic.exe start Start-Process komorebi -WindowStyle hidden ``` However nothing happens after this and on running `komorebi.exe state` I see this output: ``` PS C:\Users\naoey> komorebic.exe state Error: No connection could be made because the target machine actively refused it. (os error 10061) Location: /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\result.rs:1675:27 ``` Attempting to run `komorebi.exe` directly there appears to be an exception on startup causing the process to terminate: ``` $env:RUST_BACKTRACE = 'full'; komorebi.exe Aug 13 11:28:17.651 INFO init: komorebi::window_manager: initialising The application panicked (crashed). Message: removal index (is 1) should be < len (is 0) Location: library\alloc\src\vec\mod.rs:1385 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ⋮ 9 frames hidden ⋮ 10: alloc::vec::{{impl}}::remove::assert_failed<unknown> at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\alloc\src\vec\mod.rs:1385 11: komorebi::workspace::Workspace::remove_window::h4846824783ba2b6e at <unknown source file>:<unknown line> 12: komorebi::windows_api::WindowsApi::load_workspace_information::h5f9f2afc54eb18e1 at <unknown source file>:<unknown line> 13: komorebi::window_manager::WindowManager::init::h5dc04cec6e26d635 at <unknown source file>:<unknown line> 14: <crossbeam_channel::flavors::array::Channel<T> as core::ops::drop::Drop>::drop::h0095431d3770ac30 at <unknown source file>:<unknown line> 15: std::sys_common::backtrace::__rust_begin_short_backtrace::h53b0089f6784328f at <unknown source file>:<unknown line> 16: std::rt::lang_start::{{closure}}::h945d8ad2027e9b68 at <unknown source file>:<unknown line> 17: core::ops::function::impls::{{impl}}::call_once<unknown> at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\ops\function.rs:280 18: std::panicking::try::do_call<unknown> at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:401 19: std::panicking::try<unknown> at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:365 20: std::panic::catch_unwind<unknown> at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panic.rs:434 21: std::rt::lang_start_internal<unknown> at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\rt.rs:34 22: main<unknown> at <unknown source file>:<unknown line> 23: invoke_main<unknown> at d:\a01\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78 24: __scrt_common_main_seh<unknown> at d:\a01\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 25: BaseThreadInitThunk<unknown> at <unknown source file>:<unknown line> 26: RtlUserThreadStart<unknown> at <unknown source file>:<unknown line> ``` This is running on the current latest master @ `c15f1e1`.
adam added the bug label 2026-01-05 14:47:35 +01:00
adam closed this issue 2026-01-05 14:47:36 +01:00
adam commented 2026-01-05 14:47:36 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Aug 13, 2021):

Thank you for this detailed report! Are you using multiple monitors by any chance? It looks like this is a bug that I didn't catch because I only use one monitor 😅.

I think you're hitting this call which tries to ensure that Windows are associated with the correct monitor.

Looking a bit further in the stack trace it seems like the issue is with this line which was recently introduced as part of the resizing feature. I think that wrapping this in an if let Some() block should resolve the issue, as remove on Vec does indeed panic when index is out of bounds instead of returning an Option<T> like remove on VecDeque.

I'll @ you in this issue when I'm able to push these changes to a branch for you to try out later today 🤞.

@LGUG2Z commented on GitHub (Aug 13, 2021): Thank you for this detailed report! Are you using multiple monitors by any chance? It looks like this is a bug that I didn't catch because I only use one monitor 😅. I think you're hitting [this call](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/windows_api.rs#L200) which tries to ensure that Windows are associated with the correct monitor. Looking a bit further in the stack trace it seems like the issue is with [this line](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/workspace.rs#L270) which was recently introduced as part of the resizing feature. I think that wrapping this in an `if let Some()` block should resolve the issue, as `remove` on `Vec` [does indeed panic](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.remove) when `index` is out of bounds [instead of returning an `Option<T>`](https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.remove) like `remove` on `VecDeque`. I'll @ you in this issue when I'm able to push these changes to a branch for you to try out later today 🤞.
adam commented 2026-01-05 14:47:36 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Aug 13, 2021):

@naoey https://github.com/LGUG2Z/komorebi/tree/hotfix/multi-monitor-startup-panic

@LGUG2Z commented on GitHub (Aug 13, 2021): @naoey https://github.com/LGUG2Z/komorebi/tree/hotfix/multi-monitor-startup-panic
adam commented 2026-01-05 14:47:36 +01:00
Author
Owner
Copy Link

@naoey commented on GitHub (Aug 14, 2021):

Yes, I do use multiple monitors. Tried this branch out and it started up successfully 👍

Another couple of questions that I had:

  1. Is there support for having a startup script similar to the yabairc file we'd use with yabai to set the initial startup configuration? It seemed to be following some default config and tiling every workspace on both screens. I set up the AHK script as well with my desired configuration but none of it seemed to be having any effect. Are there any extra steps to set up the configuration?
  2. Is a workspace the same as a a virtual desktop in the Windows multitasking paradigm, i.e. new workspaces created with Win + Ctrl + D?
@naoey commented on GitHub (Aug 14, 2021): Yes, I do use multiple monitors. Tried this branch out and it started up successfully 👍 Another couple of questions that I had: 1. Is there support for having a startup script similar to the yabairc file we'd use with yabai to set the initial startup configuration? It seemed to be following some default config and tiling every workspace on both screens. I set up the AHK script as well with my desired configuration but none of it seemed to be having any effect. Are there any extra steps to set up the configuration? 2. Is a workspace the same as a a virtual desktop in the Windows multitasking paradigm, i.e. new workspaces created with Win + Ctrl + D?
adam commented 2026-01-05 14:47:36 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Aug 14, 2021):

Right now the AHK script has to be run manually (either by double clicking it in explorer.exe or running something like Start-Process autohotkey.exe komorebi.ahk -WindowStyle hidden in PowerShell), but it's a good idea to look for it in a common directory (probably ~/.komorebi.ahk and then execute it immediately after komorebi.exe starts listening for messages on its socket. I will open a separate issue to track this.

There is currently no option that allows for a workspace without tiling. I will open a a separate ticket to track this.

Workspaces in komorebi are unrelated to Windows Virtual Desktops; they are implemented as a thin layer on top of the existing DWM by showing and hiding windows programmatically. You have a few options for workspace creation right now:

komorebic.exe ensure workspaces MONITOR_IDX DESIRED_WORKSPACE_COUNT

This is usually run at the start of a config file to ensure the minimum number of workspaces that you want to work with on each monitor.

komorebic.exe focus-workspace WORKSPACE_IDX

This will try to switch to the given workspace index on the active monitor, and if it doesn't exist, it will be created, along with any other required workspace indices on the way. For example, if you only have one workspace (0) on the monitor, and you try to focus workspace index 3, workspaces 1 and 2 will also be created in the process.

I think it's a good idea to have a command that will just append a new workspace on the currently focused monitor (similar to the Win+Ctrl+D behaviour); I'll open a separate ticket to track this.

@LGUG2Z commented on GitHub (Aug 14, 2021): Right now the AHK script has to be run manually (either by double clicking it in `explorer.exe` or running something like `Start-Process autohotkey.exe komorebi.ahk -WindowStyle hidden` in PowerShell), but it's a good idea to look for it in a common directory (probably `~/.komorebi.ahk` and then execute it immediately after `komorebi.exe` starts listening for messages on its socket. I will open a separate issue to track this. There is currently no option that allows for a workspace without tiling. I will open a a separate ticket to track this. Workspaces in `komorebi` are unrelated to Windows Virtual Desktops; they are implemented as a thin layer on top of the existing DWM by showing and hiding windows programmatically. You have a few options for workspace creation right now: ```powershell komorebic.exe ensure workspaces MONITOR_IDX DESIRED_WORKSPACE_COUNT ``` This is usually run at the start of a config file to ensure the minimum number of workspaces that you want to work with on each monitor. ```powershell komorebic.exe focus-workspace WORKSPACE_IDX ``` This will try to switch to the given workspace index on the active monitor, and if it doesn't exist, it will be created, along with any other required workspace indices on the way. For example, if you only have one workspace (`0`) on the monitor, and you try to focus workspace index `3`, workspaces `1` and `2` will also be created in the process. I think it's a good idea to have a command that will just append a new workspace on the currently focused monitor (similar to the Win+Ctrl+D behaviour); I'll open a separate ticket to track this.
adam commented 2026-01-05 14:47:36 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Aug 14, 2021):

@naoey The three enhancements on the referenced issues have been implemented and are on the master branch, you can check the commit messages for the new commands that are now available to create/append a new workspace and to configure or toggle tiling on a workspace. 🎉

@LGUG2Z commented on GitHub (Aug 14, 2021): @naoey The three enhancements on the referenced issues have been implemented and are on the `master` branch, you can check the commit messages for the new commands that are now available to create/append a new workspace and to configure or toggle tiling on a workspace. 🎉
adam commented 2026-01-05 14:47:36 +01:00
Author
Owner
Copy Link

@naoey commented on GitHub (Aug 16, 2021):

That was fast! 😄

Thanks a bunch I'll give it a spin later today.

Workspaces in komorebi are unrelated to Windows Virtual Desktops; they are implemented as a thin layer on top of the existing DWM by showing and hiding windows programmatically. You have a few options for workspace creation right now:

Ah that's where my confusion came from, as I was looking to try and disable tiling on specific Windows 10 virtual desktops. Would love to have that as a feature sometime in the future!

@naoey commented on GitHub (Aug 16, 2021): That was fast! 😄 Thanks a bunch I'll give it a spin later today. > Workspaces in komorebi are unrelated to Windows Virtual Desktops; they are implemented as a thin layer on top of the existing DWM by showing and hiding windows programmatically. You have a few options for workspace creation right now: Ah that's where my confusion came from, as I was looking to try and disable tiling on specific Windows 10 virtual desktops. Would love to have that as a feature sometime in the future!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#3
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?