## Quick Information - **Operating System:** Debian LXC in Proxmox - **Install Type:** Git Cloned (Manual) - **Crafty Version:** v4.10.6 ## What Happened? After updating to v4.10.6, the python3 process consumes 95-100% of a CPU core continuously only while a minecraft server is running. Previously was around 1-3% total. ## Expected result Normal, previous CPU usage of v4.10.4 at around 1-3 percent. ## Steps to reproduce Update crafty from 4.10.4 to 4.10.6 via provided shell script (update_crafty.sh). Start any MC server, observe python3 CPU usage with "ps aux". ## Screenshots No screenshots but here is the output before and after the "fix" detailed below. Before `crafty 8890 93.6 1.1 1392228 144428 ? Sl 20:48 31:29 python3 main.py -d` After `crafty 9326 0.8 0.7 1387228 94164 ? Sl 21:39 0:02 python3 main.py -d` Notice 93.6% usage dropped to .8 percent. ## Priority/Severity - [x] High (anything that impacts the normal user flow or blocks app usage) - [ ] Medium (anything that negatively affects the user experience) - [ ] Low (anything else e.g., typos, missing icons/translations, layout/formatting issues, etc.) --- Fair warning, AI helped me find and fix this issue so I'm not 100% familiar with some of this stuff. After noticing my CPU was at 25% total package usage rather than the normal 2-4%, I used `ps aux` to identify that crafty's python3 process was consuming basically 100% of an entire core non-stop. py-spy was used to dump the thread stack traces which revealed the virtual_terminal thread was active+gil, meaning it was the thread holding python's global interpreter lock and actively spinning: `Thread 8945 (active+gil): "virtual_terminal" check (server.py:184)` Inspecting app/classes/shared/server.py revealed the cause which was the check() method has the timeout parameter set to 0.00 passed to queue.get() inside a while true loop which created a busy-wait that spins at 100% CPU whenever the queue is empty: `def check(self, batch_size=20, timeout=0.00): while True: try: line = self._queue.get(timeout=timeout)` Was able to band-aid fix this by changing the timeout from 0.00 to 0.05 in the method's params. After this, crafty's CPU usage returned to the previous 1-3% as it was in v4.10.4.