1.4.230 UI hangs/unresponsive #5631
Comments
Cyruz143
added
bug
Krzmbrzl
added
client
and removed
triage
|
Could you perhaps run Mumble through a debugger? That way we know where the GUI thread gets stuck. |
Not a developer by trade, can you give specific steps to follow? Edit: Found instructions on the wiki, attaching log. |
|
The file you sent me actually contains the output of the console. You can use WinDbg to get a backtrace. |
|
That file is from WinDbg. I just followed the steps on the wiki. |
|
Sorry, you're right. Did you load the debug symbols before obtaining the backtrace? |
|
Looks like I didn't, I've added a newer trace here. It looks like the debugger also hangs when it's trying to dump the callstack, I left it sat there for 5 minutes, F5'd and then tried another breakpoint. Wouldn't log any further than the last line regarding |
|
Thanks, I'm fairly sure that's indeed the issue: How many handles and threads exist according to Windows' task manager when Mumble freezes? |
|
537 Handles and 14 Threads. Really weirdly, open task manager will cause mumble to unfreeze a bit (system interrupt?). Enough that I can see the server list but it's still frozen after that and I cannot close it etc. |
|
537 handles and 14 threads for the entire operating system? Here's the task manager on my VM for comparison:
|
|
That was just the handles and threads for Mumble itself. Do you want system wide? |
|
Yes, thanks. |
|
|
|
Looks perfectly fine to me, I'm pretty sure you're encountering https://bugreports.qt.io/browse/QTBUG-94570. I'll rebuild the vcpkg environment as soon as possible so that new builds will use a version of Qt that should theoretically have a fix for the bug. |
|
Nice, if you can compile a quick Windows build when you have a chance, I'd be happy to test it to ensure it's resolved. |
|
Update on this: We found that the issue should be fixed in Qt 5.15.4, but apparently this release is only available to folks subscribing to the extended support releases. For us mere mortals, the last available release is 5.15.2. Since this issue is no longer actionable for us, I'll close this issue as out of our control. EDIT: References: |
Krzmbrzl
added
the
external-bug
|
@Cyruz143 We updated the build environment with Qt 5.15.4; could you check whether the issue persists with the latest artifact from CI, please? |
|
Still exhibits the same issue sadly. Will try and get more debugging data when I have the time. |
|
In that case, this doesn't seem to be the Qt bug after all 🤔 👀 |
Krzmbrzl
removed
the
external-bug
|
Unless the bug is in multiple places... |
|
@Cyruz143 do you have any peripherals other than keyboard and mouse connected to your computer? If so, could you try unplugging them and then check whether the issue persists? See also https://forums.mumble.info/topic/14467-14-conflict-with-flight-control-rudder-pedals/ |
|
I just tried it with 1.4.274 and it works fine now... Flight pedals plugged in still, all seems to work fine now. Something fixed in between current stable and 1.4.230 perhaps? |
|
Lol xD
Not intentionally, but we take what we get ^^ |
|
I'm on 1.4.287 and I'm currently getting this exact issue. At first I was able to get it to go away by unplugging some USB sound cards I had (that worked fine with other apps), but now even with them disconnected I get a hard freeze of the Mumble UI as soon as it starts up. This is the tail of my log: Note the same "Failed to create a timer" message at the end. Any ideas? |
|
Could you run |
It's just running endlessly...
|
|
Just to add, similar to the thread linked above (https://forums.mumble.info/topic/14467-14-conflict-with-flight-control-rudder-pedals/) I also have multiple analog HID peripherals connected. I disconnected them all and Mumble works fine again... so they definitely seem related to this problem. I tried moving them around to different USB controllers in my system, including a couple on my motherboard and 1 dedicated PCI-E USB 3.0 card. None of these mitigations helped. |
|
Excellent, thank you very much for your report! It's now pretty much confirmed the issue is related to global shortcuts and can be encountered when at least one device is sending a lot of packets/messages. The proper solution would consist in using our own queue instead of Qt's event one. |
|
Sure thing! So does that mean that we'll eventually see this fixed in a future release? Should I fall back to 1.3.x in the meantime (from what I understand, this appeared in 1.4)? |
|
The answer is affirmative to both questions. |
…indows We've been receiving quite a few reports about the program seemingly freezing, such as forums.mumble.info/topic/14467-14-conflict-with-flight-control-rudder-pedals. Turns out there are HID devices, namely advanced controllers, that constantly send packets. The reason behind the behavior is probably to prevent games from losing track of the physical state. Qt's event dispatcher blows up and consumes all resources, leading to: QEventDispatcherWin32::registerTimer: Failed to create a timer (The current process has used all of its system allowance of handles for Window Manager objects.) As a result, the UI completely freezes due to events not being processed anymore. This commit fixes the issue by using an SPSC (Single Producer Single Consumer) queue. The event loop and 20 ms timer are removed. The latter was strictly used for XInput and G-keys polling. Both backends still work, potentially better than before: no more polling! Whenever a HID message is received, the relevant code is executed. Fixes #5631
|
Hi, I just tried v1.5.517 (1.5.x RC) and the issue still seems to be present. Should this fix be merged into that branch? |
|
It is present in that branch, but apparently it doesn't quite work. See also #6054 |
|
My Mumble (Windows client 1.4.287) recently started freezing on launch. I was testing a PC monitor at the time which was the only thing out of the ordinary. The monitor supported audio over DisplayPort (NVIDIA High Definition Audio). The NVIDIA drivers were up to date. I could replicate the issue every time. Upon disconnecting the monitor, the freezing stopped immediately. I remember seeing this issue a while back and thought that this info might be helpful in one way or another. |
|
Hello, this issue still seems to be present in v1.5.634. On connecting my device (a VRS DirectForce Pro wheel base) the mumble client will lock up and consume upto 25% of cpu time. I previously did work on 1.4.xxx builds with an older firmware on the wheelbase but after a Windows reinstall and grabbing the latest versions of all related software/firmware the issue happens. For now I've downgraded Mumble to 1.3.4 as the device handling works fine in this version with the latest firmware on the wheelbase. |
Description
Been running through this with @Krzmbrzl but we're pretty much out of ideas (initially).
Originally had 1.3.4 installed. Managed to miss the warning about upgrading. When it failed to load properly with an error about migrating shortcuts. Uninstalled 1.3.4 fully, nuked the reg keys (
Computer\HKEY_CURRENT_USER\SOFTWARE\Mumble) and the AppData folder.Running 1.4.230 gives me visible title bars but no UI, it just hangs there, no load (CPU/RAM) noted in task manager.
Manually set
Computer\HKEY_CURRENT_USER\SOFTWARE\Mumble\Mumble\lastupdateto 2 to bypass the audio wizard pop up. Still hung on Consent form. Manually setComputer\HKEY_CURRENT_USER\SOFTWARE\Mumble\Mumble\consent\pingserversdialogviewedto true to bypass the consent pop up. Still hangs on load.Re-installed 1.3.4, all works fine.
Tried the mumble_client-1.5.183-x64 snapshot, same issue as 1.4.230.
Steps to reproduce
1, Open Mumble
2. App hangs
Mumble version
1.4.230
Mumble component
Client
OS
Windows
Reproducible?
Yes
Additional information
No response
Relevant log output
Screenshots
The text was updated successfully, but these errors were encountered: