1.4.230 UI hangs/unresponsive

[Cyruz143]

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\lastupdate to 2 to bypass the audio wizard pop up. Still hung on Consent form. Manually set Computer\HKEY_CURRENT_USER\SOFTWARE\Mumble\Mumble\consent\pingserversdialogviewed to 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

<W>2022-04-21 10:45:54.633 G15LCDEngine_lglcd: Logitech LCD Manager not detected.
<D>2022-04-21 10:45:54.634 libopus 1.3.1-97-g6b6035ae from C:/Program Files/Mumble/client/opus.dll
<W>2022-04-21 10:45:54.637 CELT bitstream 8000000b from C:/Program Files/Mumble/client/celt0.0.7.0.dll
<W>2022-04-21 10:45:54.639 Theme: "Mumble"
<W>2022-04-21 10:45:54.639 Style: "Lite"
<W>2022-04-21 10:45:54.639 --> qss: ":themes/Mumble/Lite.qss"
<W>2022-04-21 10:45:54.640 Locale is "en_GB" (System: "en_GB")
<W>2022-04-21 10:45:54.770 Database SQLite: "3.35.5"
<W>2022-04-21 10:45:54.793 Updating application palette
<W>2022-04-21 10:45:54.800 XboxInput: using XInput DLL 'XInput1_4.dll'
<W>2022-04-21 10:45:54.800 XboxInput: using XInputGetStateEx() as querying function.
<W>2022-04-21 10:45:54.902 QMetaObject::connectSlotsByName: No matching signal for on_qtvUsers_customContextMenuRequested(QPoint,bool)
<W>2022-04-21 10:45:55.052 AudioInput: Opus encoder set for high quality speech
<W>2022-04-21 10:45:55.052 AudioInput: 40000 bits/s, 48000 hz, 480 sample
<W>2022-04-21 10:45:55.055 WASAPIInput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.057 WASAPIOutput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.074 WASAPIInput: Mic Stream format 1
<W>2022-04-21 10:45:55.075 WASAPIInput: Stream Latency 0 (1056)
<W>2022-04-21 10:45:55.230 AudioInput: Initialized mixer for 2 channel 48000 hz mic and 0 channel 48000 hz echo
<W>2022-04-21 10:45:55.259 WASAPIOutput: Output stream format 1
<W>2022-04-21 10:45:55.259 WASAPIOutput: Stream Latency 0 (2880)
<W>2022-04-21 10:45:55.259 WASAPIOutput: Periods 10000us 3000us (latency 0us)
<W>2022-04-21 10:45:55.259 WASAPIOutput: Buffer is 60000us (5)
<W>2022-04-21 10:45:55.260 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-04-21 10:45:55.266 AudioInput: Opus encoder set for high quality speech
<W>2022-04-21 10:45:55.266 AudioInput: 40000 bits/s, 48000 hz, 480 sample
<W>2022-04-21 10:45:55.268 WASAPIOutput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.268 WASAPIInput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.280 WASAPIInput: Mic Stream format 1
<W>2022-04-21 10:45:55.280 WASAPIInput: Stream Latency 0 (1056)
<W>2022-04-21 10:45:55.462 WASAPIOutput: Output stream format 1
<W>2022-04-21 10:45:55.462 WASAPIOutput: Stream Latency 0 (2880)
<W>2022-04-21 10:45:55.462 WASAPIOutput: Periods 10000us 3000us (latency 0us)
<W>2022-04-21 10:45:55.462 WASAPIOutput: Buffer is 60000us (5)
<W>2022-04-21 10:45:55.463 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-04-21 10:45:55.463 WASAPIInput: Echo Stream format 1
<W>2022-04-21 10:45:55.463 AudioInput: Initialized mixer for 2 channel 48000 hz mic and 2 channel 48000 hz echo
<W>2022-04-21 10:45:55.479 AudioInput: Opus encoder set for high quality speech
<W>2022-04-21 10:45:55.479 AudioInput: 40000 bits/s, 48000 hz, 480 sample
<W>2022-04-21 10:45:55.481 WASAPIOutput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.481 WASAPIInput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.492 WASAPIInput: Mic Stream format 1
<W>2022-04-21 10:45:55.492 WASAPIInput: Stream Latency 0 (1056)
<W>2022-04-21 10:45:55.680 WASAPIOutput: Output stream format 1
<W>2022-04-21 10:45:55.680 WASAPIOutput: Stream Latency 0 (2880)
<W>2022-04-21 10:45:55.680 WASAPIOutput: Periods 10000us 3000us (latency 0us)
<W>2022-04-21 10:45:55.680 WASAPIOutput: Buffer is 60000us (5)
<W>2022-04-21 10:45:55.681 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-04-21 10:45:55.681 WASAPIInput: Echo Stream format 1
<W>2022-04-21 10:45:55.681 AudioInput: Initialized mixer for 2 channel 48000 hz mic and 2 channel 48000 hz echo
<W>2022-04-21 10:45:55.690 AudioInput: Using RNNoise as noise canceller
<W>2022-04-21 10:45:55.690 AudioInput: ECHO CANCELLER ACTIVE

Screenshots

[davidebeatrici]

Could you perhaps run Mumble through a debugger? That way we know where the GUI thread gets stuck.

[Cyruz143]

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

[davidebeatrici]

The file you sent me actually contains the output of the console.

You can use WinDbg to get a backtrace.

[Cyruz143]

That file is from WinDbg. I just followed the steps on the wiki.

[davidebeatrici]

Sorry, you're right. Did you load the debug symbols before obtaining the backtrace?

[Cyruz143]

Looks like I didn't, I've added a newer trace here. debug_symbols.txt

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 QEventDispatcherWin32

[davidebeatrici]

Thanks, I'm fairly sure that's indeed the issue:

<X>2022-04-22 19:35:00.376 QEventDispatcherWin32::registerTimer: Failed to create a timer (The current process has used all of its system allowance of handles for Window Manager objects.)(263c.39ac): Break instruction exception - code 80000003 (first chance)

How many handles and threads exist according to Windows' task manager when Mumble freezes?

[Cyruz143]

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.

[davidebeatrici]

537 handles and 14 threads for the entire operating system?

Here's the task manager on my VM for comparison:

[Cyruz143]

That was just the handles and threads for Mumble itself. Do you want system wide?

[davidebeatrici]

Yes, thanks.

[Cyruz143]

[davidebeatrici]

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.

[Cyruz143]

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.

[Krzmbrzl]

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. Therefore, we will unfortunately not be able to fix the issue you are encountering until Qt decides to publish a version containing this fix and make it available to the general public.

Since this issue is no longer actionable for us, I'll close this issue as out of our control.

EDIT: References:

• https://wiki.qt.io/Qt_5.15_Release#Qt_5.15_LTS_Commercial_Releases
• https://www.qt.io/blog/commercial-lts-qt-5.15.4-released
• https://bugreports.qt.io/browse/QTBUG-94570

[davidebeatrici]

microsoft/vcpkg#24660

@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?

[Krzmbrzl]

(Which is available from https://dev.azure.com/Mumble-VoIP/Mumble/_build/results?buildId=6054&view=artifacts&pathAsName=false&type=publishedArtifacts)

[Cyruz143]

Still exhibits the same issue sadly. Will try and get more debugging data when I have the time.

[Krzmbrzl]

In that case, this doesn't seem to be the Qt bug after all :thinking: :eyes:

[davidebeatrici]

Unless the bug is in multiple places...

[Krzmbrzl]

@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/

[Cyruz143]

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?

[Krzmbrzl]

Lol xD

Something fixed in between current stable and 1.4.230 perhaps?

Not intentionally, but we take what we get ^^

[mikeev261]

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:

<W>2022-10-23 19:45:17.846 WASAPIOutput: Periods 10000us 2666us (latency 0us)
<W>2022-10-23 19:45:17.846 WASAPIOutput: Buffer is 60000us (5)
<W>2022-10-23 19:45:17.846 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-10-23 19:45:17.849 WASAPIInput: Mic Stream format 1
<W>2022-10-23 19:45:17.849 WASAPIInput: Stream Latency 0 (1056)
<W>2022-10-23 19:45:17.860 WASAPIInput: Echo Stream format 1
<W>2022-10-23 19:45:17.860 AudioInput: Initialized mixer for 1 channel 48000 hz mic and 2 channel 48000 hz echo
<W>2022-10-23 19:45:17.888 AudioInput: Using Speex as noise canceller
<W>2022-10-23 19:45:17.888 AudioInput: ECHO CANCELLER ACTIVE
<X>2022-10-23 19:46:16.817 QEventDispatcherWin32::registerTimer: Failed to create a timer (The current process has used all of its system allowance of handles for Window Manager objects.)

Note the same "Failed to create a timer" message at the end.

Any ideas?

[davidebeatrici]

Could you run rawinput.exe from Joystick-Input-Examples_e2f196877de59134ac1499351d8e7391f4c6a3e0.zip and send here a screenshot of the window, please?

[mikeev261]

Could you run rawinput.exe from Joystick-Input-Examples_e2f196877de59134ac1499351d8e7391f4c6a3e0.zip and send here a screenshot of the window, please?

It's just running endlessly...

[mikeev261]

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.

[davidebeatrici]

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.

[mikeev261]

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)?

[davidebeatrici]

The answer is affirmative to both questions.