[BUG]: Insufficient buffer space #196

@AlexRumak commented on GitHub (Apr 17, 2023):

The red is edited for privacy

@AlexRumak commented on GitHub (Apr 17, 2023): The red is edited for privacy

adam commented

@LGUG2Z commented on GitHub (Apr 17, 2023):

As far as I can tell, all of the UDS sockets being opened by komorebic are being shutdown correctly via the Drop trait implementation.

There is a suggestion in this MSDN article to increase the max number of ephemeral TCP ports (I'm not sure if the UDS implementation on Windows is backed by TCP ports?).

I think this will be quite tough to diagnose as there are a finite number of ephemeral ports available on a given system which can be used by any number of applications at any given time.

@LGUG2Z commented on GitHub (Apr 17, 2023): As far as I can tell, all of the UDS sockets being opened by `komorebic` are being [shutdown correctly via the `Drop` trait implementation](https://github.com/haraldh/rust_uds_windows/blob/f45ff960e335a50fb82bef97306858d3e6198355/src/stdnet/socket.rs#L278). There is a suggestion in [this MSDN article](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/connect-tcp-greater-than-5000-error-wsaenobufs-10055) to increase the max number of ephemeral TCP ports (I'm not sure if the UDS implementation on Windows is backed by TCP ports?). I think this will be quite tough to diagnose as there are a finite number of ephemeral ports available on a given system which can be used by any number of applications at any given time.

adam commented

@AlexRumak commented on GitHub (Apr 18, 2023):

Yeah - anything I can do to gather more telemetry for when this happens?

I believe it might have something to do with microsoft teams. When you are in a teams call and you minimize a call, a small window comes up and it interacts very weirdly with komorebi - so I might face it again soon.

@AlexRumak commented on GitHub (Apr 18, 2023): Yeah - anything I can do to gather more telemetry for when this happens? I believe it might have something to do with microsoft teams. When you are in a teams call and you minimize a call, a small window comes up and it interacts very weirdly with komorebi - so I might face it again soon.

adam commented

@LGUG2Z commented on GitHub (Apr 26, 2023):

Unfortunately I don't think there is anything we can do on the komorebi, because while the UDS socket path can be reserved, if the underlying UDS implementation on Windows is backed by ephemeral TCP ports, there is no way to reserve a port for use by komorebi that will be available even with other applications (Teams etc.) are making heavy use of ephemeral TCP ports and reducing their availability.

I think the best way forward for now would be to increase the system ephemeral TCP port limit and see if the same behaviour still persists. If increasing the limit does indeed resolve this, we can add the guidance to the readme.

@LGUG2Z commented on GitHub (Apr 26, 2023): Unfortunately I don't think there is anything we can do on the `komorebi`, because while the UDS socket path can be reserved, if the underlying UDS implementation on Windows is backed by ephemeral TCP ports, there is no way to reserve a port for use by `komorebi` that will be available even with other applications (Teams etc.) are making heavy use of ephemeral TCP ports and reducing their availability. I think the best way forward for now would be to increase the [system ephemeral TCP port limit](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/connect-tcp-greater-than-5000-error-wsaenobufs-10055) and see if the same behaviour still persists. If increasing the limit does indeed resolve this, we can add the guidance to the readme.

adam commented

@AlexRumak commented on GitHub (Apr 27, 2023):

No worries! I will attempt to reproduce sometime this week or next, and if I do reproduce I will try and increase the system ephemeral TCP port limit and try to reproduce again.

Perhaps removing Teams for komorebi management would also work - or modifying teams to not produce the mini windows it does on minimization which were causing issues as well I think.

@AlexRumak commented on GitHub (Apr 27, 2023): No worries! I will attempt to reproduce sometime this week or next, and if I do reproduce I will try and increase the system ephemeral TCP port limit and try to reproduce again. Perhaps removing Teams for komorebi management would also work - or modifying teams to not produce the mini windows it does on minimization which were causing issues as well I think.

adam commented

@symplrdudley commented on GitHub (May 31, 2023):

Related Issue: https://github.com/LGUG2Z/komorebi/issues/277 from Oct 2022

@symplrdudley commented on GitHub (May 31, 2023): Related Issue: https://github.com/LGUG2Z/komorebi/issues/277 from Oct 2022

adam commented

@LGUG2Z commented on GitHub (Jun 13, 2023):

https://github.com/LGUG2Z/komorebi/commit/6df91d7d403595fc7a09599f0f5d7c01da7dbd54 Could any of you try running this build?

@LGUG2Z commented on GitHub (Jun 13, 2023): https://github.com/LGUG2Z/komorebi/commit/6df91d7d403595fc7a09599f0f5d7c01da7dbd54 Could any of you try running this build?

adam commented

@AlexRumak commented on GitHub (Jun 13, 2023):

Hi I will try soon. Thanks!

@AlexRumak commented on GitHub (Jun 13, 2023): Hi I will try soon. Thanks!

adam commented

@LGUG2Z commented on GitHub (Jul 3, 2023):

I have received a few reports on Discord from people using this build and above that they haven't seen the error since updating. Hopefully someone in this thread can also confirm. 🤞

@LGUG2Z commented on GitHub (Jul 3, 2023): I have received a few reports on Discord from people using this build and above that they haven't seen the error since updating. Hopefully someone in this thread can also confirm. 🤞

adam commented

@symplrdudley commented on GitHub (Jul 6, 2023):

I have received a few reports on Discord from people using this build and above that they haven't seen the error since updating. Hopefully someone in this thread can also confirm. 🤞

To upgrade, simply install a newer version? Or do we need to uninstall and reinstall?

@symplrdudley commented on GitHub (Jul 6, 2023): > I have received a few reports on Discord from people using this build and above that they haven't seen the error since updating. Hopefully someone in this thread can also confirm. 🤞 To upgrade, simply install a newer version? Or do we need to uninstall and reinstall?

adam commented

@LGUG2Z commented on GitHub (Jul 6, 2023):

You can go to the latest Actions job (https://github.com/LGUG2Z/komorebi/actions/runs/5432501944) and download the artifacts, then either replace your current komorebi and komorebic exes with the ones in the release subfolder, or run the wix installer; I think the latter makes more sense if you installed with WinGet, and the former makes more sense if you installed with scoop.

@LGUG2Z commented on GitHub (Jul 6, 2023): You can go to the latest Actions job (https://github.com/LGUG2Z/komorebi/actions/runs/5432501944) and download the artifacts, then either replace your current `komorebi` and `komorebic` exes with the ones in the `release` subfolder, or run the `wix` installer; I think the latter makes more sense if you installed with WinGet, and the former makes more sense if you installed with `scoop`.

adam commented

@symplrdudley commented on GitHub (Jul 6, 2023):

You can go to the latest Actions job (https://github.com/LGUG2Z/komorebi/actions/runs/5432501944) and download the artifacts, then either replace your current komorebi and komorebic exes with the ones in the release subfolder, or run the wix installer; I think the latter makes more sense if you installed with WinGet, and the former makes more sense if you installed with scoop.

I used the WinGet install method. Just double-click on the komorebi-x86_64-pc-windows-msvc.zip/wix/komorebi-x.x.x-x86_64.msi?

@symplrdudley commented on GitHub (Jul 6, 2023): > You can go to the latest Actions job (https://github.com/LGUG2Z/komorebi/actions/runs/5432501944) and download the artifacts, then either replace your current `komorebi` and `komorebic` exes with the ones in the `release` subfolder, or run the `wix` installer; I think the latter makes more sense if you installed with WinGet, and the former makes more sense if you installed with `scoop`. I used the WinGet install method. Just double-click on the `komorebi-x86_64-pc-windows-msvc.zip/wix/komorebi-x.x.x-x86_64.msi`?

adam commented

@symplrdudley commented on GitHub (Jul 6, 2023):

Ah, nevermind. I already have 0.1.16 installed.

I won't be much help.

@symplrdudley commented on GitHub (Jul 6, 2023): Ah, nevermind. I already have 0.1.16 installed. ![image](https://github.com/LGUG2Z/komorebi/assets/130775229/6a70739a-898f-439a-a007-d46c059a55ed) I won't be much help.

adam commented

@LGUG2Z commented on GitHub (Jul 7, 2023):

This build is actually a prerelease of 0.1.17, it's just not tagged yet ^

@LGUG2Z commented on GitHub (Jul 7, 2023): This build is actually a prerelease of 0.1.17, it's just not tagged yet ^

adam commented

@LGUG2Z commented on GitHub (Jul 15, 2023):

@AlexRumak @symplrdudley The changes I referenced earlier in this thread were released in v0.1.17; let me know how it goes. 🤞

@LGUG2Z commented on GitHub (Jul 15, 2023): @AlexRumak @symplrdudley The changes I referenced earlier in this thread were released in `v0.1.17`; let me know how it goes. 🤞

adam commented

@AlexRumak commented on GitHub (Jul 15, 2023):

Hi,

Been a bit too busy and haven't been using it since the bug kept occurring
but ill definitely give it a go when I get a chance!

Great news and thanks

On Sat, Jul 15, 2023 at 4:33 PM جاد @.***> wrote:

@AlexRumak https://github.com/AlexRumak @symplrdudley
https://github.com/symplrdudley The changes I referenced earlier in
this thread were released in v0.1.17; let me know how it goes. 🤞

—
Reply to this email directly, view it on GitHub
https://github.com/LGUG2Z/komorebi/issues/401#issuecomment-1636785654
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEJPNBUB5YECM47H5XXMGQLXQKS5JBFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVIZTEMJSGY4TQNBWGCSG4YLNMWUWQYLTL5WGCYTFNSWHG5LCNJSWG5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KM5DPOBUWG44TQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJTHEYDQNZTGEYDBAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDCNRXGEZDCOBUGIZIFJDUPFYGLJLMMFRGK3FFOZQWY5LFVIZTEMJSGY4TQNBWGCTXI4TJM5TWK4VGMNZGKYLUMU
.
You are receiving this email because you were mentioned.

Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
.

@AlexRumak commented on GitHub (Jul 15, 2023): Hi, Been a bit too busy and haven't been using it since the bug kept occurring but ill definitely give it a go when I get a chance! Great news and thanks On Sat, Jul 15, 2023 at 4:33 PM جاد ***@***.***> wrote: > @AlexRumak <https://github.com/AlexRumak> @symplrdudley > <https://github.com/symplrdudley> The changes I referenced earlier in > this thread were released in v0.1.17; let me know how it goes. 🤞 > > — > Reply to this email directly, view it on GitHub > <https://github.com/LGUG2Z/komorebi/issues/401#issuecomment-1636785654> > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEJPNBUB5YECM47H5XXMGQLXQKS5JBFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVIZTEMJSGY4TQNBWGCSG4YLNMWUWQYLTL5WGCYTFNSWHG5LCNJSWG5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KM5DPOBUWG44TQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJTHEYDQNZTGEYDBAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDCNRXGEZDCOBUGIZIFJDUPFYGLJLMMFRGK3FFOZQWY5LFVIZTEMJSGY4TQNBWGCTXI4TJM5TWK4VGMNZGKYLUMU> > . > You are receiving this email because you were mentioned. > > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> > . > >

adam commented

@LGUG2Z commented on GitHub (May 12, 2024):

I believe this has been fixed, please re-open if the issue still persists

@LGUG2Z commented on GitHub (May 12, 2024): I believe this has been fixed, please re-open if the issue still persists

adam commented

@xidsyed commented on GitHub (Sep 1, 2024):

Version Info:

Intel(R) Core(TM) i5-8250U CPU
Windows 23H2 Build 22631.4037

komorebi 0.1.28
tag:v0.1.28
commit_hash:0cdce8fc
build_time:2024-07-15 16:06:31 +00:00
build_env:rustc 1.79.0 (129f3b996 2024-06-10),stable-x86_64-pc-windows-msvc

Hi 👋

My first day using komorebi .I have been tinkering the whole day now. It's lovely. But im its crashed un-expectedly atleast 10 or so times today, I'd just be navigating around and suddenly hotkeys wont work until i stop and start komorebic.

At first it was windows virtual desktop that it wasnt playing nicely with, but then after disabling that, it still crashed a bunch. i ensured it was never the whkd daemon. In fact, i went ahead trying to reproduce the crash, and noted down exact cause, and troublehooting steps. Leaving it here for anyone who'd find it useful.

Event 1

whkd alive in task manager
komorebic unresponsive, doesnt respond to komorebic stack-all etc.
komorebic log doesnt prnit anything
restarting windowed whkd still responsive, nothing prints until
- alt + l focus right command, prints and works. then everything works. first time not restarting komorebic!

Event 2

closed a program > switched to different workspace, where stacked container was focused > tried cycing windows > UNRESPONSIVE
- tried windowed whkd > failed to bind all hotkeys > might already be in use
- stop and start windowed whkd > works, all commands going through > komorebic unresponding, and komorebic commands not working
- spammed alt + p and alt + (1-4) works again

Event 3

spammed alt [ and alt ] really fast in succession
- komerobi tiles new windows, but does not respond to commands stack / focus up
- hotkeys not responding
- awhkd consuming keybinds (cant swap with upper row in obsidian using shorcut) > using stop process discontinues this behaviour
- restarted whkd > spamming keys didnt help
- still tiles new windows tho :|
- komerobic start runs and komorebic gui >

thread 'main' panicked at komorebi-gui\src/main.rs:146:71:
called `Result::unwrap()` on an `Err` value: Os { code: 10055, kind: Uncategorized, message: "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full." }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

then

komorebic focus left
Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)

Location:
    komorebic\src/main.rs:1311:22

komorebic focus left
Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)

Location:
    komorebic\src/main.rs:1311:22
PS C:\Users\mmsye> ^C
PS C:\Users\mmsye> komorebic log
2024-09-01T17:44:45.614268Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:focus_window{idx=1}: komorebi::container: focusing window
2024-09-01T17:44:45.622242Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating
2024-09-01T17:44:45.624092Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:focus_window{idx=1}: komorebi::container: focusing window
2024-09-01T17:44:45.625293Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:focus_container{idx=2}: komorebi::workspace: focusing container
2024-09-01T17:44:45.641324Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}: komorebi::process_event: processed: (hwnd: 722080, title: Komorebic Crash Investigation - Home - Obsidian v1.6.7, exe: Obsidian.exe, class: Chrome_WidgetWin_1)
2024-09-01T17:44:50.373583Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:focus_window{idx=0}: komorebi::container: focusing window
2024-09-01T17:44:50.379226Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating
2024-09-01T17:44:50.381346Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:focus_window{idx=0}: komorebi::container: focusing window
2024-09-01T17:44:50.381948Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:focus_container{idx=3}: komorebi::workspace: focusing container
2024-09-01T17:44:50.384183Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}: komorebi::process_event: processed: (hwnd: 2689764, title: Administrator: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)

komorebic stack-all
Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)

Location:
    komorebic\src/main.rs:1311:22


komorebic retile
Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)

Location:
    komorebic\src/main.rs:1311:22

most other commands give the same error 👆. even

komorebic stop
Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)

Location:
    komorebic\src/main.rs:1311:22

followed instructions here to edit registry and change MaxUserPort to DWORD Value data: 65534. (didnt restart. no change).

killed komorebic from task manager
start komorebic.
works as intended :|

Will restart pc after registry change, and update experience tomorrow.
Cheers!

@xidsyed commented on GitHub (Sep 1, 2024): ### Version Info: Intel(R) Core(TM) i5-8250U CPU Windows 23H2 Build 22631.4037 komorebi 0.1.28 tag:v0.1.28 commit_hash:0cdce8fc build_time:2024-07-15 16:06:31 +00:00 build_env:rustc 1.79.0 (129f3b996 2024-06-10),stable-x86_64-pc-windows-msvc # Hi 👋 My first day using komorebi .I have been tinkering the whole day now. It's lovely. But im its crashed un-expectedly atleast 10 or so times today, I'd just be navigating around and suddenly hotkeys wont work until i stop and start komorebic. At first it was windows virtual desktop that it wasnt playing nicely with, but then after disabling that, it still crashed a bunch. i ensured it was never the `whkd` daemon. In fact, i went ahead trying to reproduce the crash, and noted down exact cause, and troublehooting steps. Leaving it here for anyone who'd find it useful. ## Event 1 - whkd alive in task manager - komorebic unresponsive, doesnt respond to `komorebic stack-all` etc. - komorebic log doesnt prnit anything - restarting windowed whkd still responsive, nothing prints until - `alt + l` focus right command, prints and works. then everything works. first time not restarting komorebic! ## Event 2 - closed a program > switched to different workspace, where stacked container was focused > tried cycing windows > UNRESPONSIVE - tried windowed whkd > failed to bind all hotkeys > might already be in use - stop and start windowed whkd > works, all commands going through > komorebic unresponding, and komorebic commands not working - spammed `alt + p` and `alt + (1-4)` works again ## Event 3 - spammed `alt [` and `alt ]` really fast in succession - komerobi tiles new windows, but does not respond to commands `stack / focus up` - hotkeys not responding - awhkd consuming keybinds (cant swap with upper row in obsidian using shorcut) > using stop process discontinues this behaviour - restarted whkd > spamming keys didnt help - still tiles new windows tho :| - komerobic start runs and komorebic gui > ``` thread 'main' panicked at komorebi-gui\src/main.rs:146:71: called `Result::unwrap()` on an `Err` value: Os { code: 10055, kind: Uncategorized, message: "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full." } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` - then ``` komorebic focus left Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) Location: komorebic\src/main.rs:1311:22 komorebic focus left Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) Location: komorebic\src/main.rs:1311:22 PS C:\Users\mmsye> ^C PS C:\Users\mmsye> komorebic log 2024-09-01T17:44:45.614268Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:focus_window{idx=1}: komorebi::container: focusing window 2024-09-01T17:44:45.622242Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating 2024-09-01T17:44:45.624092Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:focus_window{idx=1}: komorebi::container: focusing window 2024-09-01T17:44:45.625293Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}:focus_container{idx=2}: komorebi::workspace: focusing container 2024-09-01T17:44:45.641324Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 722080, animation: Animation { hwnd: 722080 } })}: komorebi::process_event: processed: (hwnd: 722080, title: Komorebic Crash Investigation - Home - Obsidian v1.6.7, exe: Obsidian.exe, class: Chrome_WidgetWin_1) 2024-09-01T17:44:50.373583Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:focus_window{idx=0}: komorebi::container: focusing window 2024-09-01T17:44:50.379226Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating 2024-09-01T17:44:50.381346Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:focus_window{idx=0}: komorebi::container: focusing window 2024-09-01T17:44:50.381948Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}:focus_container{idx=3}: komorebi::workspace: focusing container 2024-09-01T17:44:50.384183Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2689764, animation: Animation { hwnd: 2689764 } })}: komorebi::process_event: processed: (hwnd: 2689764, title: Administrator: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS) komorebic stack-all Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) Location: komorebic\src/main.rs:1311:22 komorebic retile Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) Location: komorebic\src/main.rs:1311:22 ``` most other commands give the same error 👆. even ``` komorebic stop Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) Location: komorebic\src/main.rs:1311:22 ``` followed instructions [here](https://github.com/LGUG2Z/komorebi/issues/401#issuecomment-1511702036) to edit registry and change `MaxUserPort` to DWORD Value data: `65534`. (didnt restart. no change). - killed komorebic from task manager - start komorebic. - works as intended :| Will restart pc after registry change, and update experience tomorrow. Cheers!

adam commented

@LGUG2Z commented on GitHub (Sep 2, 2024):

The detailed report and repro is appreciated! As you can probably tell from the lack of activity on this issue this is the first time we've seen a recurrence of these errors for quite a while now 🤔

@LGUG2Z commented on GitHub (Sep 2, 2024): The detailed report and repro is appreciated! As you can probably tell from the lack of activity on this issue this is the first time we've seen a recurrence of these errors for quite a while now 🤔

adam commented

@xidsyed commented on GitHub (Sep 2, 2024):

The detailed report and repro is appreciated! As you can probably tell from the lack of activity on this issue this is the first time we've seen a recurrence of these errors for quite a while now 🤔

thanks 😊.

I was trying to track down the issue for myself. I'll update if the registry change fixed it for me.

btw love what you're doing. the tool, the videos and the support for children's relief in palestine. I came for a tiling wm but stayed for the community and the vibes.

@xidsyed commented on GitHub (Sep 2, 2024): > The detailed report and repro is appreciated! As you can probably tell from the lack of activity on this issue this is the first time we've seen a recurrence of these errors for quite a while now 🤔 thanks 😊. I was trying to track down the issue for myself. I'll update if the registry change fixed it for me. btw love what you're doing. the tool, the videos and the support for children's relief in palestine. I came for a tiling wm but stayed for the community and the vibes.

adam commented

https://github.com/user-attachments/assets/06f02ab2-2346-4294-bd4d-9e0cb88de530

@xidsyed commented on GitHub (Sep 2, 2024):

Steps to Reproduce Crash

Spam komorebi for 4-5 seconds by holding down keys.
1. Komorebi unresponsive Whkd responsive
2. It tiles newly created windows, switches focus to clicked window etc, and logs those events too but doent respond to hotkeys or commands from the terminal. So far as usual.

Spam hotkeys for 10 seconds more or so.

whkd logs normally
After some more time 👇

Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)

Location:
    komorebic\src/main.rs:1311:22
> komorebic cycle-stack next
Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)

> komorebic stop
Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)
Location:
komorebic\src/main.rs:1311:22

> komorebic state
thread 'main' panicked at komorebic\src/main.rs:1335:23:
An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Intrestingly, komorebi still tiles new windows, and focuses clicked windows, and displays containers properly and logs them etc. ONLY thing that doesnt work as expected are the commands/hotkeys

I have attached the video below showing steps to reproduce the error. I noticed that when recording my screen komorebi became unresponsive fairly quickly, whereas normally it tends to take longer than that. CPU Load might be a factor in all this.

@xidsyed commented on GitHub (Sep 2, 2024): ## Steps to Reproduce Crash ![seUK5y7.png](https://i.imgur.com/seUK5y7.png) 1. Spam komorebi for 4-5 seconds by holding down keys. 1. Komorebi unresponsive Whkd responsive 2. **It tiles newly created windows, switches focus to clicked window etc, and logs those events too** but doent respond to hotkeys or commands from the terminal. So far as usual. 2. Spam hotkeys for 10 seconds more or so. 1. whkd logs normally 2. After some more time 👇 ``` Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) Location: komorebic\src/main.rs:1311:22 > komorebic cycle-stack next Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) > komorebic stop Error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) Location: komorebic\src/main.rs:1311:22 > komorebic state thread 'main' panicked at komorebic\src/main.rs:1335:23: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (os error 10055) note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` Intrestingly, komorebi still tiles new windows, and focuses clicked windows, and displays containers properly and logs them etc. ONLY thing that doesnt work as expected are the commands/hotkeys I have attached the video below showing steps to reproduce the error. I noticed that when recording my screen komorebi became unresponsive fairly quickly, whereas normally it tends to take longer than that. **CPU Load might be a factor in all this.** https://github.com/user-attachments/assets/06f02ab2-2346-4294-bd4d-9e0cb88de530

adam commented

https://github.com/firezone/firezone/issues/6454

@LGUG2Z commented on GitHub (Sep 2, 2024):

Did a quick search to see how others might be handling this issue and came up with these two links:

https://github.com/spellshift/realm/blob/30088664846fe38cafe6ea042f55a1b3d957a2c7/implants/lib/eldritch/src/pivot/port_scan_impl.rs#L234

@LGUG2Z commented on GitHub (Sep 2, 2024): Did a quick search to see how others might be handling this issue and came up with these two links: https://github.com/firezone/firezone/issues/6454 https://github.com/spellshift/realm/blob/30088664846fe38cafe6ea042f55a1b3d957a2c7/implants/lib/eldritch/src/pivot/port_scan_impl.rs#L234

adam commented

@xidsyed commented on GitHub (Sep 2, 2024):

Disclaimer
Not a rust dev, nor do i know much about IPCs on OSes. Both mentions seem to not really have a fix for the issue. they just throw errors, and judging by the state of those issues, their systems seem to recover.

Im assuming that komorebic uses UDS to communicate with komerobi. And when there are other programs also making use of these ephemeral sockets or (we're spamming requests), they can get exhausted quite quickly. I don't understand however, is why would komorebic not recover after a short while, and how does a restart fix it all of a sudden. maybe during load it doesnt fully let go of the resources, and only when its restarted does that get taken care of.

Why Restarts Work:

OS finallyy gets around to cleanup of resources it allotted to komorebic
Resources, that we aren't clearing get cleaned up
Some inconsistent internal state is being reset.
Idk if we are using connection pooling, maybe we should. and if we are, maybe we're not recycling resources properly, or maybe

Potential Fixes:

Implement a "soft reset" feature for connections. that doesnt require having to restart the program
Better connection pooling??
Queing? Rate Limiting? Exponential Backoff? 🤷‍♂️

(excuse the stupidity, im not any good at this 🥲)

@xidsyed commented on GitHub (Sep 2, 2024): **Disclaimer** Not a rust dev, nor do i know much about IPCs on OSes. Both mentions seem to not really have a fix for the issue. they just throw errors, and judging by the state of those issues, their systems seem to recover. Im assuming that komorebic uses UDS to communicate with komerobi. And when there are other programs also making use of these ephemeral sockets or (we're spamming requests), they can get exhausted quite quickly. I don't understand however, is why would komorebic not recover after a short while, and how does a restart fix it all of a sudden. maybe during load it doesnt fully let go of the resources, and only when its restarted does that get taken care of. Why Restarts Work: 1. OS finallyy gets around to cleanup of resources it allotted to komorebic 2. Resources, that we aren't clearing get cleaned up 3. Some inconsistent internal state is being reset. Idk if we are using connection pooling, maybe we should. and if we are, maybe we're not recycling resources properly, or maybe Potential Fixes: Implement a "soft reset" feature for connections. that doesnt require having to restart the program Better connection pooling?? Queing? Rate Limiting? Exponential Backoff? 🤷‍♂️ (excuse the stupidity, im not any good at this 🥲)

adam commented

@xidsyed commented on GitHub (Sep 2, 2024):

As far as I can tell, all of the UDS sockets being opened by komorebic are being shutdown correctly via the Drop trait implementation.

I guess that implementation could be stress tested manually

@xidsyed commented on GitHub (Sep 2, 2024): > As far as I can tell, all of the UDS sockets being opened by `komorebic` are being [shutdown correctly via the `Drop` trait implementation](https://github.com/haraldh/rust_uds_windows/blob/f45ff960e335a50fb82bef97306858d3e6198355/src/stdnet/socket.rs#L278). I guess that implementation could be stress tested manually

adam commented

@LGUG2Z commented on GitHub (Sep 2, 2024):

Just as a sanity check can you also try running the latest nightly release? https://github.com/LGUG2Z/komorebi/releases/tag/nightly

@LGUG2Z commented on GitHub (Sep 2, 2024): Just as a sanity check can you also try running the latest nightly release? https://github.com/LGUG2Z/komorebi/releases/tag/nightly

adam commented

@xidsyed commented on GitHub (Nov 11, 2024):

I'm running

komorebi 0.1.30
tag:v0.1.30
commit_hash:9a3dbccc
build_time:2024-11-03 23:49:52 +00:00
build_env:rustc 1.82.0 (f6e511eec 2024-10-15),stable-x86_64-pc-windows-msvc

Looking for configuration files in C:\Users\mmsye

Found komorebi.json; this file can be passed to the start command with the --config flag

Found C:\Users\mmsye\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag

this is the most frustrating bug in komorebi unfortunately,

Every once in a while i will minimize a window, or shift it accross workspaces, and things break a little or need to be retiled or komorebi needs to be restarted and windows need to be sent to their correct workspaces. but this only happens a few times a week honestly. and is no big issue for all the convenience that komrebi offers.

But komorebi randomly becoming unresponsive, not responding to keybindings or terminal commands, happens approx 10 times a day. every singel day. for me. this happens while:

all other keybinds in whkd work
komorebi continues to log events like, change in window focus or workspace focus etc.
komorebi continues to tile new windows
it just S TOPS responing to komorebic commands from the terminal AND shortcuts from whkd.

im honestly astounded that I'm the only one facing this issue. i've come so close to calling it sometimes 😭. when it stops responding and i realize ill have to restart komorebi causing all the (15 or so) windows to shift workspace 1, and others need to be unminimzed with the alt+tab and sent to their correct workspaces.

2 alternative fixes that would improve this experience

if there was some way for komorebi to save state accross restarts and remember which window what belongs to
the workspace rules should have windows tiled in the correct worksapcs without having to un-minimize the window, then clicking on it | NOTE : bringnig the window into focus is not enough i have to click on it for it to realise (oops i'm not in my assigned workspace).

despite all this komorebi continues to make life easy for me. but man does this bug ruin the experience.

@xidsyed commented on GitHub (Nov 11, 2024): I'm running ``` komorebi 0.1.30 tag:v0.1.30 commit_hash:9a3dbccc build_time:2024-11-03 23:49:52 +00:00 build_env:rustc 1.82.0 (f6e511eec 2024-10-15),stable-x86_64-pc-windows-msvc ``` ``` Looking for configuration files in C:\Users\mmsye Found komorebi.json; this file can be passed to the start command with the --config flag Found C:\Users\mmsye\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag ``` this is the most frustrating bug in komorebi unfortunately, Every once in a while i will minimize a window, or shift it accross workspaces, and things break a little or need to be retiled or komorebi needs to be restarted and windows need to be sent to their correct workspaces. but this only happens a few times a week honestly. and is no big issue for all the convenience that komrebi offers. But komorebi randomly becoming unresponsive, not responding to keybindings or terminal commands, happens **approx 10 times a day. every singel day.** for me. this happens while: 1. all other keybinds in whkd work 2. komorebi continues to log events like, change in window focus or workspace focus etc. 3. komorebi continues to tile new windows **it just S TOPS responing to `komorebic` commands from the terminal AND shortcuts from whkd.** im honestly astounded that I'm the only one facing this issue. i've come so close to calling it sometimes 😭. when it stops responding and i realize ill have to restart komorebi causing all the (15 or so) windows to shift workspace 1, and others need to be unminimzed with the `alt+tab` and sent to their correct workspaces. 2 alternative fixes that would improve this experience 1. if there was some way for komorebi to save state accross restarts and remember which window what belongs to 2. the workspace rules should have windows tiled in the correct worksapcs without having to un-minimize the window, then clicking on it | NOTE : bringnig the window into focus is not enough i have to click on it for it to realise (oops i'm not in my assigned workspace). despite all this komorebi continues to make life easy for me. but man does this bug ruin the experience.

adam commented

@LGUG2Z commented on GitHub (Nov 11, 2024):

Please test #1112

@LGUG2Z commented on GitHub (Nov 11, 2024): Please test #1112

adam commented

@xidsyed commented on GitHub (Nov 12, 2024):

Will update in a day

@xidsyed commented on GitHub (Nov 12, 2024): Will update in a day

adam commented