AlexRumak commented 1 year ago

Describe the bug I am not sure how to reproduce, but see the image. I cannot stop komorebic via komorebic stop command as I get the following error: 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)

To Reproduce Unfortunately, I do not know how to reproduce yet.

Expected behavior komorebic should terminate. I am guessing a deadlock potentially?

Screenshots and Videos Operating System OS Name: Microsoft Windows 11 Pro OS Version: 10.0.22621 N/A Build 22621

Additional context The window tiling was acting really weird. I am not sure if that contributed to the error. I will try and reproduce and follow up in this ticket when I get more information. In the meantime, please let me know how I can get more telemetry for this issue in a PII safe way?

AlexRumak commented 1 year ago

This was the type of weird tiling that prompted me to try and restart the program:

AlexRumak commented 1 year ago

The red is edited for privacy

LGUG2Z commented 1 year ago

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.

AlexRumak commented 1 year ago

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.

LGUG2Z commented 1 year ago

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.

AlexRumak commented 1 year ago

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.

symplrdudley commented 1 year ago

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

LGUG2Z commented 1 year ago

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

AlexRumak commented 1 year ago

Hi I will try soon. Thanks!

LGUG2Z commented 1 year ago

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. 🤞

symplrdudley commented 1 year ago

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?

LGUG2Z commented 1 year ago

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.

symplrdudley commented 1 year ago

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 1 year ago

Ah, nevermind. I already have 0.1.16 installed.

I won't be much help.

LGUG2Z commented 1 year ago

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

LGUG2Z commented 1 year ago

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

AlexRumak commented 1 year ago

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 .

LGUG2Z commented 4 months ago

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

xidsyed commented 2 weeks ago

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!

LGUG2Z commented 2 weeks ago

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 🤔

xidsyed commented 2 weeks ago

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 2 weeks ago

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.
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

LGUG2Z commented 2 weeks ago

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

xidsyed commented 1 week ago

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 1 week ago

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

LGUG2Z commented 1 week ago

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

LGUG2Z / komorebi

[BUG]: Insufficient buffer space #401

Version Info:

Hi 👋

Event 1

Event 2

Event 3

Steps to Reproduce Crash